Role-based access control (RBAC) simplifies access management and makes a company’s distributed resources more secure. Identity-based policies are challenging to manage and make the theft of over-permissioned credentials more damaging. By comparison, assigning users and permissions to well-defined roles makes access policies more flexible and easier to manage.

This article will introduce role-based access control and how it works. While RBAC has disadvantages, the productivity, security, and financial benefits far outweigh the risks. Twingate’s Zero Trust access control solution can take role-based access to the next level — and we will show you how.

What is RBAC?

In the past, organizations commonly aligned access policies with their organizational structures or assigned permissions individually on an ad hoc basis. These approaches over-permission users, giving them access to more network resources than they need. Should hackers compromise over-credentialed accounts, they can penetrate deeper into the network and access more sensitive data.

Role-based access control lets organizations implement least privilege access principles to minimize these risks. Rather than defining policies by workgroup or individual need, RBAC defines policies for users’ various roles within the organization. This approach lets users access the network resources they need to do their job while minimizing the risks of over-permissioned accounts.

The various types of RBAC share three common elements:

• Users - RBAC models consider users to be any person or system that needs access to protected resources.

• Roles - Very few of the functions users across the organization perform are - unique to an individual. Roles group common functions so permissions can be applied to many users.

• Permissions - These are the rules defining how a particular resource may be accessed. A resource’s permissions can vary from role to role.

When companies develop an RBAC system, they first identify types of users, roles, and the permissions needed for secure access. Each role is assigned a set of permissions that define what that role is allowed to do. Finally, users are assigned one or more roles depending on their job responsibilities.

RBAC policies can be broad, while other network resources may be much narrower:

• All users may access email from the company WiFi network.

• HR administrators have read/write access to HR management systems.

• Accounts payable administrators may generate payments.

• Accounts payable supervisors may approve payments.

Note that these policies give users specific types of access to specific resources. A user must be assigned a new role to receive different permissions.

What are the benefits of RBAC?

Assigning users to roles with specific permissions makes access control more flexible and responsive while reducing administrative costs and security risks. Some benefits of RBAC include:

• Flexibility - RBAC models optimize access policies to match an organization’s unique requirements. Levels of responsibility, separation of duties, and other business rules can be built into the role and permission definitions.

• Ease of maintenance - RBAC lets companies automate permission assignment and reduce administrative burdens. Administrators can onboard new users quickly through simple interfaces. Changes to roles or permissions automatically apply to all users with those roles.

• Consistency and compliance - Enterprises can apply consistent access policies across their organizations. Auditing tools can identify policy conflicts and document compliance with regulations or industry best practices.

• Lower risk exposure - RBAC implements least privilege principles to shrink an organization’s attack surface. When hackers compromise a user account, RBAC constrains the number of resources they may access.

Implementing RBAC also has a financial benefit. A decade after defining RBAC standards, the National Institute of Standards and Technology (NIST) evaluated RBAC’s economic impact. The report estimated that companies were saving $1.8 billion per year through process efficiencies alone.

Four RBAC models

Government agencies, enterprises, and IT vendors were already implementing elements of role-based access when the NIST introduced the RBAC model in 1992. A lack of consistency, however, made adoption difficult. The NIST shepherded RBAC through the standards-setting process until its official adoption in 2004 as ANSI/INCITS 359-2004, Role Based Access Control. This standard defined four RBAC models with progressively greater capabilities:

Flat RBAC

Flat BRAC consists of the users, roles, and permissions discussed earlier. Permissions are assigned to a role, and users assigned to a role acquire those permissions. Many-to-many assignments let users have many roles. Likewise, permissions may be assigned to many roles.

Flat RBAC systems must let administrators see each user’s assigned roles for auditing purposes. Additionally, administrators must have visibility of all the users assigned to each role.

Hierarchical RBAC

Building upon Flat RBAC, Hierarchical RBAC systems let organizations define role hierarchies. These hierarchies can be general or restricted to structures such as organizational trees.

Hierarchical RBAC systems can simplify role-based access control by reducing the number of unique roles an organization must manage. However, inheritance creates a risk of senior users acquiring more permissions than they truly need. Access to production servers, for example, should not roll up to the CEO.

Hierarchical RBAC systems let companies structure hierarchies and roles to limit inheritance.

Constrained RBAC

Constrained RBAC adds separation of duties (SOD) features to Hierarchical RBAC. For centuries, organizations have used SOD to control quality, limit fraud, and prevent conflicts of interest.

Constraints may be set statically to prevent users from having two conflicting roles. The accounts payable roles mentioned earlier are examples of static constraints. Letting the same user generate and approve payments creates opportunities for fraud. Constraints prevent this conflict of interest.

Constraints may also apply dynamically to prevent the permissions of certain roles from being used at the same time. For example, an employee role lets users submit expense reports that a manager can approve. Dynamic constraints ensure that managers cannot approve their expense reports.

Symmetric RBAC

The fourth level, Symmetric RBAC, addresses the needs of large enterprises. Different administrators can assign users, roles, and permissions in different workgroups. Symmetric RBAC adds auditing functions that allow the review of permissions by user and by role. The system can show every permission a user receives directly from their assigned roles and indirectly from their inherited roles.

Disadvantages of RBAC

Although role-based access control offers clear benefits, organizations often run into roadblocks that make fully implementing RBAC difficult.

• Complex deployment - Developing a comprehensive definition of users, roles and permissions is not trivial. Even large companies rarely have the expertise to define role-based policies. Instead, enterprises must bring in specialized role engineers to help them through the process.

• Balancing security with simplicity - The more narrowly an organization defines its roles to improve security, the more administrative burdens it creates. In addition, there are always certain combinations of users and resources that do not fit neatly into the RBAC model. Extra security policies must address the resulting exceptions.

• Layered roles and permissions - Over-permissioning is still possible within an RBAC system when users are assigned or inherit too many roles. Security administrators must constantly audit the assignment of roles and permissions to ensure least privilege principles are consistently applied.

One of the largest obstacles organizations confront when implementing RBAC is the perceived cost of the deployment process. The NIST economic analysis found that American businesses spent $5 billion implementing RBAC. Ultimately, these up-front costs were offset by $11 billion in operational savings.

How Twingate can help

Twingate offers a simple solution for companies migrating to Zero Trust, role-based access control. Twingate’s all-software solution requires no changes to network infrastructure or resource settings. This light touch means you can implement Zero Trust access control in phases. Prioritize the teams and resources most at risk before expanding to the rest of the company.

Twingate allows admins to set policies and contextual permissions based on device posture, geolocation and other security risks. These policies are enforced at the resource and the client before the two endpoints connect.

Role-based access control with Twingate

Role-based access control is an essential element in modern network security and access. Given the distributed way business works today, VPN and other legacy technologies impose too many performance, productivity, and security penalties. Setting RBAC policies within a Zero Trust secure access solution such as Twingate makes access easy to manage and networks more secure.

Our free starter tier lets you try Zero Trust Network access at home or with small teams. Or contact us to learn how Twingate can make role-based access control simpler, more scalable, and more secure.