Companies and or­gan­isa­tions only assign access per­mis­sions in their IT systems to users who actually need them to carry out their activ­it­ies. This protects sensitive data from un­au­thor­ised access and modi­fic­a­tion. To ensure that security is main­tained in large or­gan­isa­tions, in­di­vidu­al access per­mis­sions are defined in an access-control list (ACL). This does have a dis­ad­vant­age. The larger the number of users, the more high main­ten­ance and error prone the as­sign­ment of in­di­vidu­al per­mis­sions will be. A flexible yet efficient al­tern­at­ive 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­gan­isa­tion’s IT in­fra­struc­ture. The key term here is ‘role-based’. This is what dis­tin­guishes RBAC from other security ap­proaches, such as mandatory access control. In this model, a system ad­min­is­trat­or assigns a security level and category to each user and object. The operating system auto­mat­ic­ally 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­gan­isa­tion and vary from company to company. To ef­fect­ively break down user roles, you could do this by de­part­ment, location, cost centre or employee re­spons­ib­il­it­ies.

How role-based access control works

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

  • Modi­fic­a­tion per­mis­sions for data (e.g. read, read and write, full access)
  • Access per­mis­sions for company ap­plic­a­tions
  • Per­mis­sions within the ap­plic­a­tions

To fully benefit from the ad­vant­ages of the RBAC model, the first step is always to establish a model for the roles and per­mis­sions. This involves the or­gan­isa­tion assigning all employee re­spons­ib­il­it­ies to specific roles which determine the cor­res­pond­ing access per­mis­sions. Then, the roles are assigned to employees according to their re­spons­ib­il­it­ies. Role-based access control allows you to assign one or more roles per user. This also lets you in­di­vidu­ally 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 activ­it­ies without having to make any ad­di­tion­al modi­fic­a­tions.

RBAC is im­ple­men­ted 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­it­or­ing, and updating all iden­tit­ies 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 stand­ard­ised 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 auto­mat­ic­ally alerts the ad­min­is­trat­ors. They can then im­me­di­ately 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­gan­isa­tions define roles which are usually based on the or­gan­isa­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 ne­ces­sar­ily 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­gan­isa­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­gan­isa­tion, employees working in the same de­part­ment carry out similar activ­it­ies. 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­res­pond­ing per­mis­sions are assigned to all employees within a de­part­ment.

The third level: re­spons­ib­il­it­ies

Ad­di­tion­al per­mis­sions are defined based on the employees’ re­spons­ib­il­it­ies and cor­res­pond­ing tasks.

Tip

Team leaders know their employees’ tasks best. It is, therefore, re­com­men­ded to include them in the process of defining roles. By using an IAM system, per­mis­sions can auto­mat­ic­ally be requested and confirmed with the de­part­ment heads.

The bottom level: roles

In many cases, employees must perform activ­it­ies that were not pre­vi­ously covered by the role request for their de­part­ment and re­spons­ib­il­it­ies. Therefore, the or­gan­isa­tion will ul­ti­mately 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­gan­isa­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 re­com­men­ded to in­cor­por­ate 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­vant­ages and dis­ad­vant­ages 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­men­ted and enforced through­out the company, RBAC can offer numerous ad­vant­ages:

  • Flex­ib­il­ity: The company only assigns roles to an employee as required. Any modi­fic­a­tions to the or­gan­isa­tion­al structure or per­mis­sions are quickly applied to all employees when the company modifies the cor­res­pond­ing role.
  • Reduced ad­min­is­tra­tion work: RBAC has rendered the time-consuming process of in­di­vidu­ally assigning per­mis­sions obsolete.
  • Less error prone: Assigning per­mis­sions in­di­vidu­ally 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­ciency: Reducing the amount of work and error rate increases the ef­fi­ciency of IT and other employees. There is no longer any need for manual modi­fic­a­tions, error handling, wait times or in­di­vidu­al per­mis­sion requests.
  • Security: Access per­mis­sions are defined ex­clus­ively via the role model which prevents you from giving more per­mis­sions than needed to in­di­vidu­al employees. This is in line with the Principle of Least Privilege (PoLP).
  • Trans­par­ency: The naming of roles is usually straight­for­ward and thus increases trans­par­ency and com­pre­hens­ib­il­ity for users.

Role-based access control also has some dis­ad­vant­ages:

  • Labour-intensive setup: Trans­lat­ing or­gan­isa­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­por­ar­ily, it is easier to forget about them when using RBAC than when assigning per­mis­sions in­di­vidu­ally.
  • Ap­plic­a­tion: In small companies, creating and main­tain­ing roles would be more labour intensive than assigning per­mis­sions in­di­vidu­ally. 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­gan­isa­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