Role-based Access Control: Why it’s often not enough to manage the APPocalypse/App Assignment Process

Get the Facts—and kill the IT ticket—in Our CIO’s Guide

Employees use an average of 100 apps in the workplace and IT must manage access in a way that’s secure and compliant. To do this, IT teams often use role-based access control (RBAC). RBAC allows IT to group users into roles and automatically assign and unassign app access based on what they need to do their jobs. However, IT teams are still inundated with access requests, burying them in support tickets and torpedoing employee productivity while they wait.So, what’s the answer? RBAC and self-service.Our Insider’s Guide to RBAC and Self-Service has all you need to know to make sure you’re automating app access and managing app and permissions sprawl—all while killing the IT ticket.

Introducing Lumos

IT teams spend way too much time tracking help desk tickets for routine access requests. And employees spend way too much time waiting to get access to the apps they need to do their jobs.

Lumos Is on a Mission To Change That

Lumos takes access management and the ITIL experience to the next level by combining the workflow automation power of an identity governance and administration tool with the visibility and cost management controls of a SaaS management solution.

The result: a single solution that helps IT teams achieve compliance, drive productivity, and manage costs with workflow automation that handles employee access requests, access reviews, and SaaS app license removals.

Request a Demo

Onboarding + Off-Boarding Automation

Streamline onboarding and rely on one-click off-boarding to manage app access and permissions.

Employee Self-Service Access Requests

Employees can see and request access to the apps they need to do their jobs.

Access Reviews

Speed through your SOX, SOC2, HIPAA, and ISO27001 audit prep with audit-friendly reporting.

Ready To Learn More About How We Can Help Transform Your IT Operations?

Visit Lumos

The Basics of RBAC

This article will help you understand the basics of RBAC and how it can help your team better manage access across your company resources and applications. You’ll learn more about the basics, the benefits, and the challenges of RBAC. You’ll also find out the difference between RBAC, ACL, and ABAC, what's possible, and how to implement a successful RBAC strategy for your organization.

What is RBAC?

IT teams worldwide use RBAC to secure their company information. In a nutshell, RBAC limits or restricts employee access to specific parts of the company network, such as apps, tools, files, or data. It’s one of four types of access control that companies use to manage employee access and permissions. The other three types are mandatory, discretionary, and rule-based. RBAC is a popular choice because of its simplistic approach. In theory, RBAC prevents employees from accessing anything that isn’t relevant to their jobs. That’s why it’s “role-based.”

Think about it this way: A sales representative may need access to certain bits of information to get the job done, but not others. For example, IT departments can create a “sales representative” role that designates which apps and permissions the person has and limits access to everything else. Then, any time a new sales rep is hired, that person is assigned the predefined role and the access privileges that go along with it. Simple, right? Maybe. But we’ll get to that later.

How does RBAC work?

RBAC is an easy way to manage the thousands of apps, documents, programs, and tools that companies use. RBAC is based on three types of access control: Role assignment, role-based authorization, and permission authorization. First, IT determines the resources and actions a person needs to do their job. Second, they use that information to create a role. Third, they set standard permissions, either technical or administrative, underneath that role that are automatically assigned to anyone with that position.

Those permissions grant access to system functions, documents, and other information employees need. When employees are hired, they are assigned one of the IT-created roles, giving them access to the pre-defined list of privileges. Tools, such as Microsoft Azure AD and OneLogin, allow IT teams to set RBAC privileges for the organization.

Why is RBAC important?

RBAC sets a standard for all users rather than taking a person-by-person approach, making it both replicable and scalable as the organization changes or grows. This predefined method means employees get access to the tools they need faster and with less effort from IT. In addition to helping employees become productive faster, RBAC ensures least privilege access. Least privilege means that employees only have access to what they need when they need it–and nothing more. As soon as their role within the company changes or they separate from service, their access to various tools is revoked.

How is RBAC different from ABAC and ACL?

RBAC differs from attribute-based access control (ABAC) because it’s based on employee roles rather than user characteristics, such as environment, action types, and more. ABAC attributes tend to fall into four categories: subject, action, object, and contextual. These attributes cover things like age, clearance, and department as well as the action being taken, the object being accessed, and other relevant environmental attributes.

ACL, or access-control list, technology is a user-specific list of permissions that determines which users have access to specific files, systems, processes, and resources. An ACL also determines which actions that user can take. Unlike RBAC, which clusters users together and determines access privilege based on their role, ACL is done at the user and resource  level. Typically, ACL works better for individual users while RBAC works better on a company level.

The challenge with RBAC

RBAC is an incredible tool to enact company-wide security and compliance. However, more users, more roles, and more apps all make setting up and maintaining RBAC more complex. To ensure compliance, IT teams have to ensure the least privilege access is maintained, even when users change roles or leave–and that is no small task. When IT teams can’t keep up with the changes it results in overprovisioning. This means employees keep access to tools or permissions long after they stop using the app, which can create huge security issues.  

In addition to overprovisioning concerns, RBAC also has its limitations. For example,  it can’t grant one-time permissions if exceptions need to be made. And, even with workflow automation and provisioning tools, like Okta or BetterCloud, RBAC doesn’t eliminate IT tickets for access requests.

How to implement RBAC

Setting up an RBAC system for your organization takes time–but it can be well worth the effort. First, take inventory of all company apps, resources, documents, and tools that require access permissions. Next, group your users into roles that make sense for your company. For example, sales representative, customer service, and human resources are all great starts–and you can create more granular roles, if needed. When creating roles think about what level of access a user would need in a particular role. From there you can set permissions for each role and then group your users into the roles you created. Even after initial setup, be sure to go back and periodically audit both the roles and permissions because those will likely change as the company grows.