Skip to content

The Fundamentals of Role-Based Access Control

Megan Bozman

January 8, 2021

6 minute read

RoleBasedAccessControl FeatureImage

A layperson might (and often does) assume that the biggest SaaSOps challenges are fairly straightforward, especially when it comes to granting access to your company’s data. If someone should have access, you should give it to them. And if they shouldn’t, then don’t. Right?

Of course, access control isn’t that simple—and as a result, even some of the world’s biggest companies have fallen victim to some high-profile data breaches. This statistic will likely change in the coming months as new data rolls in, but Statista reports that there were a whopping 540 data breaches in 2020. There are a variety of root causes that we could spend days analyzing, but there’s one harsh reality that IT constantly faces: It’s really hard to craft access control policies that fit your business and evolve with it as the organization grows.

The solution for many IT teams? A slightly more nuanced approach known as role-based access control (RBAC). This is not exactly a new approach, but it enables you to grant access based on the specific needs of each user’s role and business unit. Let’s take a closer look.

What is role-based access control?

Margaret Rouse of TechTarget defines role-based access control as a method of restricting network access based on the roles of individual users within an enterprise. Rouse adds, “[It] lets employees have access rights only to the information they need to do their jobs and prevents them from accessing information that doesn’t pertain to them.”

Back in 2017, Thor Pedersen created this graph to illustrate the basics of RBAC. You’ll note how each person’s access is determined by their specific role in the organization—and as a result, users are granted privileges to only the things they need.

A flowchart illustrating the association between various business roles and their designated functions tied to specific resources. Key roles include HR, Payroll, Sales, Finance, and IT Security. Each role is mapped to functions: Finance role (handling finance tasks), General role (covering general duties), Payroll (managing payroll processes), IT role (overseeing IT-related responsibilities), HR role (handling human resources tasks), and Sales role (focused on sales activities). These functions connect directly to resources such as Email, Data Center, Customer Database, SAP systems, Time Cards management system for tracking work hours, and Employee Records database. Arrows indicate the logical flow from each business role through its function(s) leading to corresponding resource(s).

How does this manifest itself in a real-world workplace? One common example is performance evaluations. Supervisors need to complete performance evaluations for each of their direct reports, but there’s no reason for them to access reviews of, well, anyone else across the organization.

Additionally, RBAC effectively manages secure user access by connecting permissions only to roles, rather than to individual users. It’s important to make sure users have the right level of access from day one. It’s very difficult to rein in access after users have been given it.

Challenges of role-based access control

Like most things that IT admins have to manage, there are some well-documented challenges of role-based access control. The following issues are incredibly common in a RBAC environment:

  • Lack of a standard definition
  • The role is the new perimeter
  • Avoiding excess permissioning
  • Achieving RBAC at scale

Let’s unpack each of these challenges in further detail.

Lack of a standard definition

According to the National Institute of Standards and Technology (NIST), role-based systems “were developed by a variety of organizations, with no commonly agreed upon definition or recognition in formal standards.”

And as you might have guessed, implementations of RBAC continued to evolve over the years. While this article is old, CSO columnist Roger A. Grimes said as recently as 2013 that, “My favorite applications are the RBAC ones where almost no one is an admin, and even the admins are limited in what they can do.” While most applications offer a variety of user roles, they typically aren’t consistent—which is an issue that IT teams are constantly trying to resolve.

The role is the new perimeter

With the legacy IT model, you had a centralized way to manage user interactions, accounts, file sharing, etc., but with SaaS apps, you no longer have that perimeter. Network-based security is no longer adequate, and you can’t think about your infrastructure as a safe place inside your company. Users are going to connect from any device and any location. This is why mitigating insider threats with proper RBAC—and securing data from the inside out—is increasingly important.

Avoiding and mitigating excess permissions

A crucial cybersecurity tenet for many years, least privilege means giving people only the permissions they need to get their job done. Excess permissioning increases risk. Simply put, the more each user has access to, the more an attacker can access if that user’s credentials are compromised.

The 2020 Verizon Data Breach Investigations Report found that 45% of breaches were caused by outsiders, and over 80% of those breaches involve brute force or the use of lost or stolen credentials. The report further notes that these hacking varieties are associated in a major way with web applications.

For these reasons and many more, IT teams rely on role-based access control to reduce the risk of a potential breach. Because users in an RBAC environment only have access to the data that’s essential to their job function(s), there are fewer entry points for a potential hacker to exploit.

Achieving RBAC at scale

User Lifecycle Management (ULM) is the practice of onboarding, offboarding, and managing user accounts on a day-to-day basis. This includes employee profiles and what they have access to within various apps. ULM can become complicated across multiple SaaS apps, with the complexity of data types, objects, and configurations across different apps. When managing SaaS apps, you need visibility into users, as well as data, app configurations, and permissions.

Scale becomes an additional challenge when managing user lifecycles across an entire digital workplace with tens or hundreds of SaaS apps. Automation with SaaSOps is crucial to onboard and offboard in a way that’s scalable and error-free, and consistently maintain access control based on real-time roles.

The compliance demands of role-based access control

IT professionals are constantly trying to stay on top of the latest compliance requirements and understand which ones might apply to their organization. Compliance is often a moving target that IT needs to chase down—and RBAC environments are no exception to that rule.

Let’s unpack some of the specific compliance demands of RBAC. Spoiler: There are quite a few of them, so get comfortable and dive in.

RBAC requires role definitions and governance

To define and govern roles, you need to, well, understand each role across your organization. Managing user accounts throughout their lifecycle, including onboarding, offboarding, and updating roles requires a reliable source of truth, typically HRIS. HRIS can enable real-time provisioning and deprovisioning for users to access authorized applications, data, and systems. Once roles have been defined and assigned, IAM technologies enforce those roles by granting— and restricting—access to technology resources accordingly.

RBAC is a way to execute least-privilege, but it can be difficult to implement with many SaaS apps. Admin permissions in apps like Google Workspace, Slack, and Dropbox are commonly all or nothing. Without granular control over admin access, permissions are either dangerously excessive or a barrier to productivity.

BetterCloud’s role-based privileges equips IT with granular permission controls and least privilege policies that guarantee your administrators have the perfect amount of access, but nothing more.

Least privilege in a SaaS world

RBAC must apply strict access controls to sensitive data, systems, and applications, enforcing least privilege by only allowing access to assets that users need to do their jobs. Unfortunately, least privilege is difficult with SaaS management due to the varying definitions of user role types and levels of granularity across SaaS apps. SaaS apps have a myriad of settings and controls for users, groups, and files.

In particular, while collaboration and file sharing enhance productivity, such functionality also increases risks. Settings can be misconfigured; files can be shared publicly without knowing it.

There are many different ways to configure the file sharing settings on platforms such as Office 365 and Box, and the implications of those choices are not always clear. The complexity of data types and objects across all SaaS apps only exacerbates the difficulties. Over time, it’s all too easy to simply grant access to more data and controls than necessary, leading to increased risk.

A survey conducted by BetterCloud found that non-SaaSOps users significantly underestimate their number of super admins per app. A similar disconnect emerges around perception versus reality for the number of files with potentially sensitive data that are accessible to the public.

Examples of cloud provider role-based access control

Most cloud providers enable granular access control. For example, with Azure RBAC you can:

  • Allow one user to manage virtual machines in a subscription and another user to manage virtual networks
  • Allow a DBA group to manage SQL databases in a subscription.
  • Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets

With Azure RBAC, access to resources is controlled by role assignments. Azure includes several built-in roles, as well as the ability to create custom roles.

Similarly, in Google Cloud, “A role contains a set of permissions that allows you to perform specific actions on Google Cloud resources.” There are three types of roles in IAM: basic, predefined, and custom roles. Google Cloud’s basic roles are, “concentric; that is, the Owner role includes the permissions in the Editor role, and the Editor role includes the permissions in the Viewer role. They were originally known as ‘primitive roles.’” The predefined roles currently total over 100.

On the other hand, Amazon Web Services uses the term attribute-based access control (ABAC). “In AWS, these attributes are called tags. Tags can be attached to IAM principals (users or roles) and to AWS resources.” According to AWS, the approach requires fewer policies and is helpful in environments that are growing rapidly.

Salesforce enables users to assign access roles to contributors according to the level of access they need in a specific workspace or community. Salesforce also provides a flexible, layered data sharing design that lets you expose different data sets to different groups of users. For example, you can enable salespeople to view only leads from their own division.

This was just a brief introduction to role-based access control. Want to see how BetterCloud can help you Discover, Manage, and Secure your SaaS environment? Schedule a demo.