Role-based access control (RBAC)

What is 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. RBAC 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).

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 organisation, 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 authorisation 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.

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. Analyse 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 organisation.
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 authorisation solution that assesses users’ attributes or characteristics, rather than roles, to determine access privileges based on an organisation’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 authorised 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 organisation-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, organisations use RBAC for coarse-grained access control, while ABAC is used for fine-grained access control.

RBAC implementation

A methodical approach is a must when implementing a role-based access control system. Time must be taken to analyse details to ensure the system meets security requirements. Specific steps that must be taken when implementing RBAC include the following.

RBAC implementation steps

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 optimised 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 organisation, 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 organisations 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 unauthorised 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, organisations can optimise 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.

Realise 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 organisations to comply with security and privacy standards included in many regulations.