Role-Based Access Control: Discover the background, benefits and best practices

We all need tools to do our job. However, it’s rarely necessary to have constant access to everything. For one thing, it’s difficult to keep track of it all. Plus, we might not use many of the tools anyway, at least not at the same time.

Instead, we only need to access the necessary tools. So that we can fulfill the duties that are part of our role. 

Of course, data is a tool. One that requires access at the right time, for the right people. That’s where Role-Based Access Control comes in.

What is Role-Based Access Control (RBAC)?

RBAC is an access control model used by many organizations to enforce user access to resources within the business. A set of roles are established and unified, with associated permissions assigned (or provisioned), and removed (deprovisioned). 

RBAC’s scope can include external users, such as contractors, vendors, and partners. Naturally, this can be extended across industries, to help meet relevant legislation, including:

• Banking and Financial Services Industry (Sarbanes-Oxley Act)
  IT professionals may be approved for logging and monitoring account and user activity, without accessing sensitive data or Personally Identifiable Information
• Healthcare (HIPAA)
  Doctors may access medical and diagnostic records, while call center operatives can only access contact details and appointment histories
• Education (FERPA)
  Administrators may access staff employment history, while lecturers only access student-related data such as academic records

First proposed in a 1992 NIST conference paper, RBAC “describes a type of non-discretionary access control”, designed to improve traditional methods for managing systems and access. Rather than assigning access based on individual identities, RBAC relies on roles, reflecting the increased need for granular permission control. By 2004, RBAC had been debated, revised, and standardized as an industry-wide consensus framework. 

Different levels of privileges are connected to roles, so anyone with a specific role automatically gains the same privileges. For example, read-only, write, execute, delete. The role hierarchy may include different roles, and so users can inherit permissions related to where the role exists within the business. These define whether access is approved, denied, or triggers another predefined workflow. 

This form of role-based access management can be applied and monitored across data, devices, networks, and all areas that require governance. Anyone without the required levels of privilege are unauthorized to gain access or perform tasks. 

What are the 3 access control models of RBAC?

Core RBAC

The RBAC core model is the foundation. It can act as a user access control method in its own right, and requires the following rules to be implemented. These refer to subjects, who can be the users within an organization. They also refer to transactions, or activities within the system:

• Role assignment
  The subject must have an active role to request, exercise, and complete transactions. The role can either be selected for the subject or assigned to them. A transaction must also be more than just a login or authentication.
• Role authorization
  The subject must have their role authorized. This helps prevent the subject taking on roles – and potentially access levels – above their authorization.
• Permission authorization
  Any transaction can only be executed when the subject’s role has the necessary permissions.

Hierarchical RBAC

Here’s where roles inherit permissions based on an organization’s hierarchy. A top-down framework may range from Super Admin, with the most permissions, down to Guest, with the fewest. 

At enterprise-level, RBAC involves assigning access to thousands of employees, often within different departments. As a result, hierarchical RBAC supports large and complex organizations with multiple roles. By segmenting access, networks can be separated and so any attacks or breaches can be more easily contained.

Constrained RBAC

This model allows more control granularity, by separating role duties in two ways:

• Static Separation of Duty
  Users can’t hold two roles that may cause conflicts of interest. For example, occupying roles for requesting and approving a purchase.
• Dynamic Separation of Duty
  Users can hold two roles that may cause conflicts of interest. However, not during the same session. This supports a two-person rule, where both are required to authorize an action.

How does RBAC benefit organizations?

• Governance
  RBAC provides a transparent framework to demonstrate that data access and management is compliant. Audit logs of role-based activity reduce the manual processing involved in meeting regulatory requirements.
• Information security
  Applying a role-based approach to access supports the Principle Of Least Privilege (POLP). Users are only granted the absolute minimum privileges to complete the desired function. This enforces access controls while reducing access points, and can support a Zero-Trust approach to information security.
• Finance
  CFOs and related roles gain compliant access to relevant data sources, for strategies around investor relations, procurement, and budgets. RBAC provides the permissioning that ensures decisions can be made quickly, based on up-to-date and relevant information sources.
• Operations
  Access to systems is predefined for new users, based on the role they’re assigned. There’s less manual authorization required for onboarding, reducing the burden on IT and HR, while users can get started quicker.

Types of role approaches

It’s common to think of roles in terms of job titles. However, with RBAC many organizations structure roles – and the associated controls – in different ways. 

After all, people come and go, get promoted or see roles change. That’s why RBAC is commonly used for functions that change less frequently than individual employee identities. For example:

• Applications
  Users may need access to specific systems as part of their role, such as a CRM or sales ledger.
• Departmental
  A consultant may have a role to optimize an operational area of the business. Access can be granted to logistical and performance-related resources, while preventing access to non-operations areas of the business. 
• Geographic
  Roles may be better defined according to location. After all, operating across borders often means different roles are required, depending on whether the business is established or launching in a local market. There’s also the requirement to localize governance policies to match regional regulations.
• Tiers
  Senior and junior roles are likely to require different levels of access as part of their contractual obligations. Establishing controls ensures there’s a clear separation between their respective duties and responsibilities.

What are some Role-Based Access Control best practices?

“Organizations should take a human-centric approach to privacy, and monitoring data should be used minimally and with clear purpose, such as improving employee experience by removing unnecessary friction or mitigating burnout risk by flagging well-being risks.”

Gartner

• Monitor continuously
  Organizations are subject to a mix of federal, regional and industry regulations. These are regularly updated, to reflect the evolving data and governance landscape. That’s why an RBAC strategy requires ongoing maintenance, validation and testing. 
• Align access to organizational structures
  To maintain consistency and minimize complexity, access should reflect organizational hierarchy. By using existing structures, there’s less need to create adhoc roles purely for permissioning.
• Identify scope and inventory systems
  Limiting the RBAC scope is one way to reduce management workloads. First, identify every resource that requires access control. Then keep the focus only on areas where sensitive data is stored and processed, rather than apply controls across the entire environment. 
• Define when and how roles can be changed
  RBAC relies on established principles for role assignment and permissions. This should include regular audits to make sure controls are optimized for specific roles, without overlap or unnecessary levels of granularity.  

What are some other forms of access control methods?

• Rule-based
  An administrator or security professional manually sets rules for user access. These rules can override existing permissions.
• Discretionary
  Decisions on user access are made by others who have similar access privileges. This can help democratize access, although it means non-security users may be approving access.
• Mandatory
  A centralized administrator manages access, using labels that classify resources. Decisions are made based on the sensitivity of the data, and the user’s level of authorization. This method is common in government and the military.
• Policy-based
  Administrators can create fine-grained policies for user access, including the permitted conditions required. Access and permissions can change dynamically, in line with legislative changes.

The model that works best depends on your use case. You’ll need to consider the types of users who will request access, including job function, location and level of security required.