Role-Based Access Control

Role-Based Access Control (RBAC), or role-based security, is an access and authorization management model in Identity Access Management (IAM) to manage application security.

This article lays out an introduction to role-based access control (RBAC) and unpacks the basics of implementing an RBAC model in your organization.

What is Role-Based Access Control (RBAC)?

A Role-Based Access Control system grants or restricts network access to a system resource based on the user’s role. The three main components of the RBAC model are roles, permissions, and users (including both humans and other systems).

The role refers to the levels of access. The business can define roles based on the seniority, department or job responsibility of a user. Permissions are equivalent to access rights and are assigned to roles in order to define and segregate different access levels. The users (with unique identifiers or UIDs) are able to assume one or more roles in order to give that user access to different resources.

The basic rules of RBAC include:

  1. Role assignment: A user can execute an operation only if the role assigned to them allows them to do so. Each user must be assigned a role.
  2. Role authorization: Roles need to be authorized, so you can’t assign a role to yourself; it needs to be authorized by someone else
  3. Permission authorization: Users can exercise only those permissions that are authorized to the subject’s role.

The National Institute of Standards and Technology (NIST) highlights four levels of RBAC.

1/ Flat RBAC: 1st Level

This is the most simplistic RBAC model. It comprises the three major components of the RBAC model: Roles, Permissions, and Users along with the three principal rules of RBAC listed above. The flat RBAC model allows one role to assign to multiple users and vice versa.

 

 

2/ Hierarchical RBAC: 2nd Level

Hierarchical RBAC is one step above the flat RBAC model. It inherits all the characteristics of the flat RBAC model, but the permission assignment follows a role hierarchy. So the senior or the upper-level roles in the system have more permissions than the junior or the lower-level roles in the role hierarchy.

3/ Constrained RBAC: 3rd Level

Constrained RBAC is one step above hierarchical RBAC. Constrained RBAC inherits all the features of hierarchical RBAC. In addition, Separation of Duties (SoD) will be included, whereby no individual user is able to complete a task on their own, and a second party is required to complete it. This creates a system of checks and balances to prevent fraudulent activity and reduce errors.

4/ Symmetric RBAC: 4th Level

Symmetric RBAC is the most advanced model of RBAC. It inherits all the characteristics of Constrained RBAC while also supporting continuous role-permission and user-role reviews. So this model facilitates identifying permissions of terminated and transferred employees and excess permission grants to comply with the principle of least privilege.

What are the Pros and Cons of RBAC?

Pros of RBAC

  • The direct and simplistic nature of RBAC makes it easy to control and maintain.  The structure of these controls makes it easy to build and maintain access to your system.

  • RBAC improves the operational efficiency of the admin team. System administrators can assign bundles of access directly to users rather than spending hours on creating new rules every time a new user needs access. Changing the access permissions of users is easier in RBAC because you only need to change them to another one of the listed predefined roles. Therefore, RBAC can automate and allocate resources to users based on their business roles without waiting for persons to manually request permission.

  • The margin of error in RBAC systems is relatively low given its lack of complexity, making it easy to manage on a limited basis. 

  • RBAC ensures compliance with security and data protection regulations such as SoC, ISO 27001, ITGC, etc. because it follows Segregation of Duties (SoD) and the principle of Least Privilege that are compulsory compliance requirements in many IT compliance and regulation standards all around the world.

  • System administrators gain increased visibility into the system and system activities as RBAC is easily auditable.

  • RBAC tends to require lower processing power and time, saving on costs in network bandwidth, storage, and memory.

Cons of RBAC

There are both advantages and disadvantages to using the RBAC model for authorization management. RBAC can provide a sound permissions management system to a limited set of users and even larger organizations with hierarchical role structures are also successfully using the RBAC model, reaping the best of the benefits of RBAC as listed below.

  • When business requirements call for an increasing number of roles for different tasks, you quickly find yourself investing a lot of time and resources to create, maintain, and control an increasing number of roles that can encapsulate these changing permissions. This proliferation can cause a ‘role explosion’ within RBAC systems. Therefore, assigning, reviewing, and modifying role assignments will become unnecessarily complex.

  • RBAC inherently lacks scalability, as mentioned above. Therefore, RBAC is not suitable for an organization with the potential to scale-out early or quickly.

  • Translating the organizational structures to RBAC roles is a labor-intensive effort. For small organizations, creating and maintaining roles is usually more labor-intensive at the start. For larger organizations, maintaining and enhancing these roles becomes as much of an effort, if not more so than building roles at the start.

How Do You Implement Role-Based Access Control?

You can use the following seven-step methodology to implement RBAC in your organization:

  1. Determine and define the resources and services within your organization that you grant user access to and which of them require access control (e.g., email systems, HR systems, operating systems, CRM, cloud applications, etc.).

  2. Analyze the pool of users against the resource pool above. Identify roles that need the same access rights.

  3. Map roles to resources such that role-to-resource functions provide access resources to complete any given task they may need to accomplish.

  4. Create security groups. A security group is organized around managing identities including objects and subjects, but not permissions. (e.g., the HR Manager role may be a member of the ‘Admin Operations’ group, of which Operations Manager, Procurement Manager, and Finance Manager are also members).

  5. Assign users to the roles you have defined and their respective security groups.

  6. Assign groups to access control lists such as mailboxes, files, and pages that contain data.

  7. Conduct periodic audits of roles and users to review permissions.

There are three major RBAC role engineering approaches you can apply when deploying RBAC to your organization.

1/ Top-Down RBAC Approach

The top-down RBAC approach cascades down, starting with the business role. You might operate on the assumption that inherently, some users have excessive permissions that can pose security threats to your organization. By understanding what applications each user has access to on a daily basis, and speaking with their manager and system admins to better understand how and where excessive permissions exist, you are able to put in place more stringent guardrails for your permissions.

Your organization’s business and IT objectives should be very closely aligned in order to implement a top-down RBAC approach successfully and effectively. But top-down role-engineering provides business oversight and business role reusability.

2/ Bottom-Up RBAC Approach

The bottom-up RBAC approach builds upon user data and technical roles. This role-engineering approach uses role mining to discover permission sets, groupings, and summary statistics in existing applications and systems. Permission sets and groupings discovered through role mining will then normalize and rationalize definition of the roles.

3/ Hybrid RBAC Approach

The hybrid role-engineering approach is a combination of top-down and bottom-up role-engineering approaches. The hybrid role-engineering approach is an industry best practice that uses normalized roles derived from the bottom-up role-engineering approach and assigns to the roles business job functions following the top-down role-engineering approach.

The management of the RBAC system in a hybrid approach represents a joint commitment from both the IT department and the businesspeople. It is helpful to keep roles and data current and readily available.

Alternatives to RBAC

Access Control Lists (ACL) and Attribute-Based Access Control (ABAC) are two alternatives to the RBAC model. However, ACL is a low-level access control model, whereas ABAC is a high-level access control model compared to the RBAC.

Access Control Lists (ACL)

Access Control Lists: Filesystems ACLs and Networking ACLs comprise a set of rules that grant or deny access to a resource. An ACL is defined as a table of rules attached to a resource such as a file, directory, firewall, etc.
However, ACLs lack scalability in comparison to RBAC. They are best for managing access control at the individual level. You cannot use ACL to manage permissions such as view, edit, and share files as with the RBAC. So ACL is a coarse-grained access management system compared to RBAC. ACLs often work best in applications such as firewall network traffic control.

Attribute-Based Access Control (ABAC)

ABAC is a more fine-grained access control system than RBAC. ABAC uses attributes that define the unique situation of a user (e.g., a manager who works in the HR department) to authorize and grant him/her the correct level of access to a system resource (e.g., the read/ write access to all the HR files). 

ABAC lets you precisely and compactly apply access rules to a resource. So ABAC is highly sensitive to security risk tolerance levels and ideal for security-critical systems. However, ABAC is a complex and computationally expensive model of access authorization.

Ready to get started?

Subscribe to build.security’s newsletter

Keep up with the latest news on our authorization policy management platform