What is Role-Based Access Control?

Most of us have visited a hotel at some point in our lives. We arrive at reception, if we request a room, they give us a key; if we are going to visit a guest, they lead us to the waiting room as a visitor; if we are going to have dinner at their restaurant, they label us as a customer; or if we attend a conference on technology, we go to their conference room. It would not be the case that we would end up in the pool or enter the laundry room for a very important reason: we were assigned a role upon arrival.

Do you know what Role-Based Access Control or RBAC is?

In the field of computing too, since its inception, all this has been taken into account, but remember that the first machines were extremely expensive and limited, so we had to settle for simpler resources before Role-Based Access Control (RBAC) arrived.

Access Control List

In 1965, there was a timeshare operating system called Multics (created by Bell Laboratories and the Massachusetts Institute of Technology) which was the first to use access control lists (ACL). I wasn’t even born at that time so I will trust what Wikipedia has to say about this topic. What I do know, first-hand, is the filesystem access control list (filesystem ACL) that Netware Novell® used in the early 1990s and that I already told you about in a previous article on this blog.

But let’s go back to the access control list: What is an access control? This is the easiest thing to explain, it is nothing more and nothing less than a simple restriction on a user regarding a resource. Either by means of a password, a physical key or even your biometric values, such as a fingerprint, for example.

An access control list then is to write down each of the users who can access (explicitly allowed) or not (explicitly prohibited, under no circumstances) something. As you may imagine, this becomes tedious, constantly staying aware of noting the users one by one and also the processes of the operating system or the programs that run on it… You see, what a mess to write down all the entries, known as access control entries (ACEs).

Following the example of rights on files, directories and beyond (such as full resources: optical disks or entire “hard drives”), I came to work, last century, with Netware Novell®. This is a Filesystem ACL (Network File System access control list). Then came the millennium shock, the NFS ACL version 4 that picked up and expanded, in a standardized way, everything we had used since 1989 when RFC 1094 established the Network File System Protocol Specification. I think I have summarized a lot and should name, at least, the use that MS Windows® gives to ACLs through its Active Directory (AD), the Networking ACLs for the cases of network hardware (routers, hubs, etc.) and the implementations that some databases make.

All these technologies, and more, make use of the concept of access control lists, and as everything in life evolves, the concept of groups sharing some similarities emerged, and thus it was possible to save work by keeping the lists of access. Now imagine that you have one, or more access control lists, that only support groups. Well, in 1997 a man named John Barkley demonstrated that this type of list is equivalent to a minimum Role-Based Access Control, but RBAC at the end of the day, which brings us to the core of the issue…

Role-based access control RBAC

The concept of role in RBAC goes beyond permissions, it can also be well-defined skills. In addition, you may have several assigned roles, depending on the needs of the protagonist (user, software, hardware…). Going back to the billing department example. A salesperson, who already has a corresponding role as such, could also have a collection role to analyze customer payments and focus their sales on solvents. With roles this is relatively easy to do.

Benefits of RBAC

• First of all, RBAC dramatically reduces the risks of breaches and data leaks. If the roles were created and assigned rigorously, the return on investment of the work done in RBAC is guaranteed.

• Reduce costs by assigning more than one role to a user. It is unnecessary to buy new virtual computers if they can be shared with groups already created. Let Pandora FMS monitor and provide you with information to make decisions about redistributing the hourly load or, if necessary and only if necessary, acquire more resources.

• Federal, state, or local regulations on privacy or confidentiality can be required of companies, and RBACs can be a great help in meeting and enforcing those requirements.

• RBACs not only help efficiency in companies when new employees are hired, they also help when third parties perform security work, audits, etc. because beforehand, and without really knowing who will come, they will already have their work space well defined in one or more combined roles.

Disadvantages of RBAC

• The number of roles can grow dramatically. If a company has 5 departments and 20 functions, we can have up to a maximum of 100 roles.

• Complexity.Perhaps this is the most difficult part: identifying and assigning all the mechanisms established in the company and translating them into RBAC. This requires a lot of work.

• When someone needs to temporarily extend their permissions, RABCs can become a difficult chain to break. For this, Pandora FMS proposes an alternative that I explain in the next section.

RBAC Rules

To take full advantage of the RBAC model, developing the concept of roles and authorizations always comes first. It is important that identity management to be able to assign these roles is also done in a standardized way, for this the ISO/IEC 24760-1 standard of 2011 tries to deal with it.

There are three golden rules for RBACs that must be displayed according to their order in time and enforced in due course:

1. Role assignment:Someone may exercise a permission only if they have been assigned a role.

2. Role authorization:The active role of a person must be authorized for that person. Along with rule number one, this rule ensures that users can only assume the roles for which they are authorized.

3. Permission authorization:Someone can exercise a permission only if the permission is authorized for the person’s active role. Along with rules one and two, this rule ensures that users can only exercise the permissions for which they are authorized.

The Enterprise version of Pandora FMS has an ultra complete RBAC and authentication mechanisms such as LDAP or AD, as well as double authentication mechanisms with Google® Auth. In addition, with the tag system that Pandora FMS handles, you may combine RBAC with ABAC. The attribute-based access control is similar to RBAC but instead of roles, it is based on user attributes. In this case, assigned labels, although they could be other values such as location or years of experience within the company, for example.

But we leave that for another article…

Before finishing this article, remember Pandora FMS is a flexible monitoring software, capable of monitoring devices, infrastructures, applications, services and business processes.

Would you like to find out more about what Pandora FMS can offer you? Find out clicking here: https://pandorafms.com/

If you have more than 100 devices to monitor, you may contact us through the form : https://pandorafms.com/contact/

Also, remember that if your monitoring needs are more limited, you have Pandora FMS OpenSource version available. Learn more information here: https://pandorafms.org/

Do not hesitate to send us your questions. Pandora FMS team will be happy to help you!