Role-Based Access Control (RBAC) Guide & How to Implement It?

Every time a company experiences a data breach, one of the first things they examine to identify the cause of the breach are the access controls. Having a robust system for controlling access to critical resources is a crucial part of any cyber-security defense strategy. Access control is achieved through two core concepts: authentication and authorization, which are used to determine that users are who they say they are and that they are authorized to access the resources they are trying to access. There are various different methods for controlling access to resources, which include; Discretionary Access Control (DAC), Mandatory Access Control (MAC), Attribute-based Access Control (ABAC), and Role-Based Access Control (RBAC). This article will focus on the latter, although I’ll provide a brief explanation of the other methods later in the article.

What is Role-Based Access Control?

Role-Based Access Control (RBAC) is one of the most commonly used methods for controlling access to the different areas of an organization’s IT system, although it is more popular with larger organizations. With RBAC, users are assigned roles, and roles are assigned permissions, such as create, read, update, and delete. In some cases, roles are grouped together to form what is referred to as “role groups”. For example, let’s say that we have a group called “medical-staff”, which has access to patient records. We could set up a group called “physician”, who is a part of the medical-staff group. The physician will inherit the permissions of the medical-staff group, but can also be granted access to information beyond that of the medical-staff group.

RBAC offers a lot of flexibility, as it can be as broad and granular as you need. However, this can also make it difficult to know where to begin, especially since a “role” in RBAC is loosely defined. For example, a role can be a job type, an action that can be performed, or a role based on how long an employee has worked for the company. A role can be based on a user’s authority, location, responsibility, or job competency.

We can think of roles like folders on our desktop, where we might store digital music downloads. We might have one folder called “chillout”, and one called “easy listening”. Since these categories are very similar, they might cause some confusion when it comes to storing new downloads. As such, an organization wishing to use RBAC should invest a sufficient amount of time designing the structure of the roles and role groups, to enforce a clear separation of duties. Fortunately, even if you make a mistake when setting up your roles, one of the benefits of RBAC is that it is relatively easy to edit and remove roles without disrupting the integrity of your system.

Below are some examples of the types of roles that are permissible when using RBAC.

• Administrator
• Editor
• End-user
• New York Branch
• Shop Admin
• Update Product Listing
• Marketing
• Send Newsletter
• Delete User Account
• Edit CNAME DNS Record
• General Practitioner
• X-ray Technician
• Financial Reporting and Control
• Tax and Compliance

As you can see from this list, there isn’t a strict naming convention or schema that can be adhered to, and it would be hard to introduce one, given the flexibility that RBAC offers. However, it is unlikely that you will be creating roles before establishing an inventory of all the different parts of your environment that need to be protected. Below is a simple example of how users are assigned roles, and roles are assigned permissions.

Let’s say that you are running an online shop. There are users who will visit your shop, a shop administrator who is responsible for managing the product listing, and a marketing department who will send out newsletters. So, we have 3 roles:

• End-User
• Shop-Admin
• Marketing

We will then assign permissions to roles like so:

End-User
catalog-item: read
user-account : create/read/edit/delete
invoice: create

Shop-Admin
catalog-item : create/read/edit/delete

Marketing
newsletter : create/read/update/delete/send
distribution-list : edit

Note that the example above is an oversimplification of how RBAC actually works. In most cases, the sysadmin will control access to a much broader range of resources, and many roles would be grouped together.

When each of these users log-in to your system, they will receive an access token, which will be checked by whatever authentication and authorization protocol you are using to determine which roles the user has access to, and thus the actions they are allowed to perform.

NOTE: You could also set up a Super-User who has full access to all parts of your application, including the files stored on the server. This level of access is typically only granted to web developers. However, should a hacker gain access to the Super-User account they can potentially bring your entire business to its knees, and so if you need to grant the web developer full access, make sure that full access is revoked when it is no longer required. A better idea would be to create separate user accounts, each with their own set of credentials, which the Super-User will log into. Likewise, it is good practice to adhere to a principle referred to as “separation of duties”.

Role-Based Access Control and Separation of Duties (SoD)

Separation of Duties is a well-known security principal that is designed to prevent conflicts of interest, fraud, and errors. The idea is that certain critical changes require the approval of more than one user, in order to be executed. The process is similar to requiring two signatures on a cheque. SoD was typically used for financial accounting systems, however, since Sarbanes-Oxley (SOX) and the Gramm-Leach-Bliley Act (GLBA) came into effect, it has become more widely used in IT security. RBAC can help to facilitate SoD by ensuring that a single user cannot approve their own changes – assuming they are of a critical nature. For example, there could be a role set up for purchasing, and a role setup for approving the purchase. A single user would not be allowed to do both. The same process could be used for accessing sensitive data, making critical changes to the server, firewall configuration, and so on.

Benefits of Role-Based Access Control

Role-Based AccessControl makes it a lot easier to manage permissions by decoupling the permissions from the users. This greatly simplifies the process of adding, editing or removing user privileges. Other benefits of Role-Based Access Control include:

• Reducing the potential for errors when assigning user permissions
• Making it easier to integrate third-parties into your system
• Eliminating the need for multiple passwords
• Making it easier to comply with data protection regulations, such as GDPR, HIPAA, GLBA, SOX, and so on
• Making it easier to implement separation of duties (SoD)

Best Practices For Implementing Role-Based Access Control

Before setting up any roles, the first thing you will need to do is create an inventory of all data, applications, and hardware where access is, or at least should be, restricted in some way. You might want to consider using automated data discovery and classification tools to ensure that you know exactly what sensitive data you have, and where it is located, before proceeding. If you are using a sophisticated key-card security system, you can also use RBAC to control access to the server room and other restricted areas.

Once you have an inventory of all resources, you will then need to set up roles to determine who can access those resources. However, since RBAC is designed to simplify the traditional method of assigning permissions on a per-user basis, you will need to be careful not to create too many roles, as that will defeat the object.

Once you have set up your roles, you will need to ensure that you have a list of all users who will have access to resources on your network. Carefully review each user and decide which roles they should be assigned to. As mentioned previously, roles can inherit permissions from role groups, and so it is a good idea to start with the role groups first and most general roles.

Create a role assignment policy which provides details about how new users should be added, and how they should be removed from your system. Managing user permissions is an ongoing process, and so you will need to regularly review your access controls and make changes accordingly. The time-scales, including the process for reviewing permissions, should be documented in your role assignment policy. You will need to ensure that RBAC has been integrated across all systems within your organization.

Role-Based Access Control in the Cloud

Cloud computing allows for easy, fast, and efficient storage and retrieval of data, in addition to providing a large number of applications and services. Many organizations will use multiple platforms and services at any one time.

As you can imagine, controlling access to a large number of different applications and services in a secure manner is a challenge. In recent years, we’ve seen a number of data breaches that have been caused by cloud-based access control systems failing to meet the demand for easy-to-configure, flexible, and fine-grained access control. However, things are at least moving in the right direction. For example, Amazon AWS now has a primitive RBAC system in place that is based on the user’s ID and includes default roles for authenticated users and guest users who are not authenticated. Google Cloud now provides Role-based Access Control (RBAC) as a part of its Kubernetes Engine. And Microsoft Azure Resource Manager uses RBAC to enable fine-grained access management of Azure resources.

The problem, as mentioned above, is that organizations are using multiple cloud platforms, and each platform has its own API for managing access. Using these APIs to integrate each platform’s authentication and authorization protocols into our existing IT environment will take time and expertise. There are some products entering the market, that claim to provide a single sign-on (SSO) solution that works with multiple cloud platforms, in addition to on-premise solutions, such as Active Directory. And while it might be possible to use RBAC with a cloud-centric SSO, there is currently little to no documentation about how this can be achieved.

Methods for Controlling Access to Resources

Discretionary Access Control (DAC) – DAC is where the owner of a particular resource is permitted to grant access to a resource at their discretion. The problem with DAC is that organizations have much less visibility and control over how resources are being accessed, and by who. It’s unlikely that a regular employee will understand the security risks associated with allowing write access to a spreadsheet, even if the spreadsheet is available to the public.

Mandatory Access Control (MAC) – MAC relies on a centralized authority to grant access to resources and is typically used by Governments and military institutions to protect highly classified information.

Attribute-based Access Control (ABAC) – ABAC uses rules written in eXtensible Access Control Markup Language (XACML) to assign specific attributes to specific users. An attribute could be a time, position, location, system, object, or any other information that can be associated with a user. The rules are saved in the form of key-value pairs, such as Role=Advisor and Category=Financial. ABAC provides more granularity than RBAC, however, RBAC is usually the preferred method as it is easier to implement and maintain.

Access control is arguably the most important aspect of data security, and RBAC provides the most efficient and scalable method for achieving it, at least for organizations that have a large number of employees. It requires minimal maintenance, eliminates the need for multiple passwords, makes it easy to add or change roles, and helps to satisfy regulatory compliance requirements.