What is role-based access control (RBAC)?

Role-based access control (RBAC) is a security methodology based on managing user access to protect resources, including data, applications, and systems, from improper access, modification, addition, or deletion. It grants access based on a user’s needs according to their position. Roles and associated privileges are defined, and permissions are assigned to control access (i.e., what a user can see), the scope of approved operations (i.e., what a user can do, such as view, create, or modify), and session time (i.e., how long a user can have access).

The evolution of RBAC in digital security landscapes

Role-based access control (RBAC) systems came about in the 1970s when multi-user and multi-application online systems were introduced. The change from one person using a single application at a time brought to the forefront the need for security controls that could give multiple users access to systems while controlling what functions and data they could use. RBAC provided a system for managing these multi-user systems and a way to review who had what access and conduct audits.

Early applications were developed with built-in RBAC functionality. As the use of these applications expanded, having RBAC built-in proved to be an issue when security controls needed to be changed or updated. This drove the move to RBAC as a stand-alone security tool that could be used to secure and manage multiple applications across user bases. With this application-level security model, administrators could create roles and apply access controls and updates to these privileges across multiple systems from a central point.

More advanced RBAC systems allowed administrators to establish relationships between users and roles. This enabled even more control with minimal administrative support, including security policies such as delegation of authority and separation of duties.

Three common principles of RBAC

With role-based access control, permissions are based exclusively on roles, which simplifies administration. When a user’s position changes, including if they sever relations with the organization, administrators simply change their role, and permissions are automatically updated. Using RBAC, users can be assigned multiple roles.

1. User role assignment defines users’ permission or access rights based on a role or task.
2. User role authorization confirms that a user is approved for a role and to perform related functions.
3. User role permission and access rights define specifically what a user can and cannot do.

Key components of RBAC systems

Operations

Operations refer to activities carried out in a computing environment. The most common operations in a computing environment are inputting, processing, outputting, storing, and controlling. An example of an operation that would be restricted with an RBAC system is changing system configurations. The management of operations permissions is usually for administrators or other power users.

Permissions

Permissions dictate which roles can access what resources and operations. They define the relationship between a role and resources and operations, which establish rules for exactly what can be done by users.

Resources or objects

Resources, also referred to as objects, are those digital assets, such as files, data stores, or systems for which users are granted permission to use (e.g., access, share, or change). RBAC systems are used to define user access permissions to resources as well as maintain usage logs that include which user accessed what resources, what was done, and the time and duration of the access.

Roles

Roles are collections of permissions that are applied to users. With RBAC systems, permitted actions are based on roles rather than individual identities. In some cases, a user may be assigned more than one role.

Roles are typically created according to hierarchies. For instance, a lower-level role would be given permission to view a file but not edit or share it.

The assignment of roles is usually based on several user traits, such as job function and location or the device they are using to access a resource. Most organizations have a set of pre-built roles based on job function.

Sessions

A session is the amount of time a user interacts with a resource or operation. It tracks when a user first engages a resource and session and when the file or application is closed. Details about the session (e.g., what was done, device connected from, and location connected from) are recorded by the RBAC system and used for auditing purposes.

Users

The user is the entity that is granted access through the assignment of a role. With RBAC systems, users are people as well as services and computing entities (e.g., endpoint devices and virtual machines). That is, users are individuals, processes, or applications that need to interact with the system.

RBAC permissions

With role-based access control, it is important to remember that permissions follow roles, not the other way around. Determine what each role should do and apply permissions accordingly. Additional considerations when setting RBAC permissions to specify what users can access and what they can do in the system include:

Access

1. Which users can open a specific item, such as a file, application, or database?
2. Which users should be aware that certain assets exist?
3. What limitations should be placed on visibility?

Modification

1. Which users can make changes to specific items?
2. What approvals are required to make changes?

Sharing

1. Which users can download a document?
2. Which users can share a document?

RBAC best practices

Best practices for the enterprise to consider when implementing role-based access control include:

1. Analyze the users, including their workflows and the resources they need.
2. Conduct audits of the roles on an ongoing basis to keep them up to date and align them with current requirements.
3. Create a basic role that includes the access every user needs.
4. Determine which roles have a common set of access requirements.
5. Ensure RBAC is integrated across all systems across the organization.
6. Establish a process for handling role changes, including setting up and decommissioning users.
7. Identify the resources that require access control.
8. Include the principles of RBAC and how it works in employee training programs.
9. Take care not to create too many roles.

Types of role-based access control

The four types of access control under the RBAC standard are core, hierarchical, symmetric, and constrained.

Core RBAC

Core role-based access control details the key components of the system. It can stand alone or be used as the base for hierarchical and constrained RBAC. Core RBAC is composed of five static elements: Users, roles, permissions, operations, and objects. The permissions are comprised of the operations, which are applied to the objects.

Hierarchical RBAC

Hierarchical role-based access control uses a hierarchy within the role structure to establish relationships between roles (e.g., senior, mid-level, junior). With hierarchical RBAC, users with senior roles are granted all of the permissions of their subordinates and those specific to their needs.

Symmetric RBAC

Symmetric role-based access control allows administrators to perform permission-role and user-role reviews to assess permissions assigned to existing roles.

Constrained RBAC

Constrained role-based access control augments core RBAC with separation of duties (SOD), which can be static or dynamic. With the static separation of duties (SSD), no user can hold mutually exclusive roles. For example, a user cannot make and approve a proposal. Dynamic separation of duties (DSD) allows users to have conflicting roles but cannot act in both roles during the same session.

Additional types of access controls

Attribute-based access control (ABAC)

Attributed-based access control is a user authorization solution that assesses users’ attributes or characteristics, rather than roles, to determine access privileges based on an organization’s security policies. With ABAC, access rules can be hyper-granular.

Access Control List (ACL)

An access control list is a table that lists the permissions associated with a resource. For each user, there is an entry that details the security attributes of each object.

An ACL lets the operating system know which users can access an object and which actions are authorized to execute. Access is granted or denied in two categories—networking and file systems. With networking, ACL is applied to routers and switches to assess the traffic.

ACL also evaluates activities and if they are allowed through the network. File systems use ACL to filter and manage access to files and directories through the operating system.

Discretionary Access Control (DAC)

Discretionary access control grants or restricts access to an object according to policy determined by an object’s owner group or subjects. DAC gives users complete control over their resources, making it less restrictive than other access control options.

With DAC, if a subject is granted permission to access an object, they can:

1. Allow users to share their privileges with other subjects.
2. Change security attributes.
3. Choose the security attributes to be associated with new or updated objects.
4. Modify the rules governing access control.
5. Share attribute information with other subjects or objects.

Mandatory Access Control (MAC)

Mandatory access control limits access to resources according to the sensitivity of the information and the level of users’ permissions. The administrators define criteria for MAC. The enforcement of MAC is handled by the operating system or a security kernel, which users cannot change.

RBAC vs. access control list (ACL)

Role-based access control and ACL serve different purposes. For example, RBAC is considered to be the best option for managing business applications and data access. On the other hand, ACL is thought to be better at handling security at the individual user level and for low-level data. Additionally, RBAC is a good fit for organization-wide security, while ACL works well for granting access to a specific file.

RBAC vs. attribute-based access control (ABAC)

The key difference between role-based access control and ABAC is how access is granted. RBAC grants access based on users’ roles and responsibilities. With ABAC, access is granted based on attributes or characteristics, such as:

User types

1. Security clearances
2. Username
3. Age
4. Job function
5. Department

Time of day

1. Lock down access to resources during the night
2. Limit edits during times when a user is not under supervision
3. Restrict access to materials on weekends

Location

1. Restrict access to a specific area (e.g., office, campus, country)
2. Deny access from specific devices (e.g., mobile phones, laptops with Wi-Fi)

Generally, organizations use RBAC for coarse-grained access control, while ABAC is used for fine-grained access control.

RBAC implementation

A systematic approach is a must when implementing a role-based access control system. This includes determining the best role-based access control model as well as understanding and preparing for each step in the implementation process.

Using RBAC models to set up roles and permissions effectively

There are three types of role-based access control models—core RBAC, hierarchical RBAC, and constrained RBAC. Understanding these is essential when implementing an RBAC system.

Core role-based access control

The core RBAC model is used for basic RBAC systems and servers as the foundation for hierarchical and restrictive RBAC models. It contains the core RBAC system components and functionality and follows the rules that apply to all RBAC models:

• Role assignments—users can only be granted access after they have been assigned a role in the RBAC system
• Role authorization—users’ roles must be validated by the RBAC system before access is granted
• Permission authorization—users can only be granted access permissions established in the RBAC system

Hierarchical role-based access control

Hierarchical role-based access control builds on the core RBAC model, introducing role hierarchies. This model structures roles based on organizational structures. Hierarchical RBAC allows sharing and inheritance between roles, and roles can be built off one another. For example:

• Guest users have a minimum set of permissions
• Regular users have guest permissions as well as additional permissions
• Power users have the permissions granted to guests and regular users and more
• Administrators have a broad set of permissions that includes those of the other user types

There are different types of hierarchies that can be applied with this model:

• Tree hierarchies are bottom-up, with the permissions at the bottom of the tree applied to those higher up, as described above.
• Inverted tree hierarchies are top-down, with higher-level roles inheriting the permissions granted to those below them.
• Lattice hierarchies blend the bottom-up and top-down approaches and make it possible for users at different levels to inherit permissions from roles above or below them.

Constrained role-based access control

Constrained role-based access control applies separation of duties (SODs) to the core model, with admins being able to use one of two types of SODs.

1. Static separation of duties dictates that no single user can have mutually exclusive roles, as defined by the organization. An example of this type of separation of duties is a person can be authorized to write checks but cannot sign them.
2. Dynamic segregation of duties allows users to be assigned conflicting roles, but they cannot perform both roles in a single session. This type of separation of duties commonly has a rule that requires two different users to approve an action. One of which can be the user with a conflicting role.

RBAC implementation steps

Time must be taken to analyze details to ensure the system meets security requirements. Specific steps that must be taken when implementing RBAC include the following.

1. Make an exhaustive inventory of all resources, including applications (i.e., on-premises and cloud), servers, documents, files, file servers, databases, and other records that require security.
2. Work with managers and human resources to identify roles.
3. Review all roles and determine how many roles should be included and which can be collapsed into blended groups.
4. Solicit feedback on the roles and input on permission levels from managers and other key constituents.
5. Assign access permissions for the roles.
6. Develop an integration timeline that includes the development of the system as well as communications to users and training.
7. Implement the plan, keeping a keen eye out for any glitches and making corrections and adjustments as needed.

Best practices for managing RBAC implementation

1. Have a written policy for how the role-based access control system should be used, including detailing the process for making changes.
2. Be receptive to input from managers and users about how the RBAC system can be optimized and make relevant changes as needed.
3. Continually evaluate roles and security status.
4. Consider the reason and implications request for any change to users’ permissions before implementing changes.
5. Enforce security protocols related to permissions.

RBAC examples

Examples of RBAC designations

Common designations in an RBAC system include:

1. Management role assignment, which connects a role to a role group
2. Management role group, from which members can be added or removed
3. Management role scope, which puts limits on which objects are managed by a role group

Examples of RBAC roles

With role-based access control, various roles within an application can be designated to users. These roles differ based on the type of application. Examples of RBAC roles include the following.

Kubernetes RBAC role assignment elements

1. Role—specifies permissions at the namespace level
2. ClusterRole—specifies permissions at the cluster level or for namespaces across the environment
3. Subject—describes a user, group, or service account
4. RoleBinding—lists subjects and their assigned roles to bind roles to entities at the namespace level
5. ClusterRoleBinding—lists subjects and assigned roles at the cluster level for every namespace in the cluster

Microsoft Azure RBAC role assignment elements

1. Principal—a user, group, service principal, or managed identity that requests a resource and is given access
2. Role definition— a set of permissions that define what a principal in a certain role can do on a resource
3. Scope—defines the resources accessible to roles and the permission levels

Examples of RBAC permissions

Role-based access control permissions are granted based on roles and access requirements. Roles and permissions are aligned with a user’s position in an organization, such as an administrator, a specialist user, or an end user. Examples of RBAC permissions are:

1. Administrative—for users that perform administrative functions
2. Billing—for an end user to access a billing account
3. Primary—for the main contact for a specific account or role
4. Technical—for users who perform technical tasks

With RBAC, users’ access permissions are tied to the common responsibilities and needs of a group, such as human resources, sales, or finance. Each role is provided with a set of permissions, as shown here:

RBAC benefits

Enable separation of duties

Since roles are separated, in theory, no single user can cause a significant breach as a hacker would be limited to whatever resources that account was permitted to access.

Enhance operational efficiency

Role-based access control simplifies administration and increases operational efficiency by providing a streamlined approach to assigning and managing access permissions. RBAC also allows administrators to quickly add and change roles and implement them across operating systems, platforms, and applications globally. This can be performed for internal and third-party users, including those who only require temporary access.

Improve compliance

Role-based access control helps organizations adhere to the data protection and privacy requirements set forth in myriad regulations by restricting access to resources.

The automation of access based on roles also supports compliance by reducing human errors that could inadvertently expose sensitive data to unauthorized users.

RBAC also provides support for auditing, which helps address compliance requirements.

Free up valuable administrative time

By reducing the amount of time administrators must spend on user permissions, role-based access control enables them up to work on higher-value, more important tasks. In addition, by limiting access to certain processes and applications, organizations can optimize the use of resources, such as network bandwidth, memory, and storage.

Increase visibility

Role-based access control gives network administrators and managers more visibility and oversight of operations and users’ activities. It also allows them to see which resources users can access to ensure compliance and adherence to security protocols.

Realize zero trust security

Role-based access control enables the implementation and enforcement of the principle of least privilege, a key tenet of zero trust security. By limiting access permissions to a user based on their roles and those required to do tasks associated with their role, RBAC significantly reduces the risk of breaches and data leakage.

RBAC for advanced user privilege management

A proven solution for user-centric security, role-based access control is the go-to for administrators. It is easy to use and reliable. RBAC protects resources and enables organizations to comply with security and privacy standards included in many regulations.