Role-Based Access Control for a complex enterprise

What is role-based access control (RBAC)?

Role-based access control, or RBAC, is the antidote to piecemeal user and permission management. RBAC provides a mechanism for system administrators to set policies and apply them as appropriate.

A core tenet of RBAC is to preemptively set rules which apply to all users, rather than making on-the-fly decisions about who should be able to access what. It also solves the problem of remembering to comprehensively revoke access when it’s no longer applicable. RBAC also enables you to implement standardized enforcement policies, demonstrating the controls required for regulatory compliance and providing users with appropriate access to get their jobs done.

RBAC makes it possible to systematically implement and manage a least privilege policy across a large geographically distributed organization, which is why it’s used by most companies with more than 500 employees. Organizations that have implemented a least privilege strategy to grant users only as much access as they need. Just as important to least privilege compliance is maintaining appropriate access over time, and effectively avoiding privilege creep whereby a user retains access to resources they no longer require.

Related reading: Least Privilege Examples

A unified approach to RBAC is critical to reducing risk and meeting compliance requirements

While RBAC has been around for many years, implementing it consistently has become increasingly challenging due to the complexity of modern use cases. With the growth of cloud services and third-party software, a unified approach to RBAC is critical to reducing risk and meeting compliance requirements.

Read on to learn more about role-based access control, how organizations go about implementing it, and how the latest approaches to RBAC streamline the process of tightly managing roles and permissions in a flexible, scalable way.

What’s so great about role-based access control?

Imagine having to explicitly grant or deny access to each database or online document for each user. Imagine onboarding a new user and having to give them permission to every individual application they will need, such as email, data repositories, internal communication tools. Most applications have at least the ability to define permissions by roles and assign users to those roles. But even with the ability to define privileges by role, not all applications have the precise controls required to grant only the precise permissions required.

For example, granting members of the HR team access within a payroll application would also allow all HR users to view compensation for all employees. So now you need to set up multiple roles, if that’s even possible, to assign certain HR roles to not show compensation. But what if the application doesn’t have the ability to hide compensation values and provide enough access for HR team members to do their job? It quickly becomes unwieldy.

Fundamentally, RBAC consists of three parts: role permissions, user-role relationships, and role-role relationships.

Role permissions: For each role that an organization defines, such as a staff accountant, engineer, security analyst, or customer support representative, IT teams to determine what resources and actions a typical person in that role would need. A resource may be a program, website, or tool, and action could include the ability to view, modify, create, or delete specific information. For example, someone who serves as a staff accountant would need access to certain financial resources and accounting software packages to fulfill their core job responsibilities. Roles can be defined globally or specifically based on organizational needs. Changes and updates to a role’s permissions can be modified as needed and should propagate to all users immediately.
User-role relationships: Each user must be assigned to at least one role. The role, or roles, they’re assigned to defines the permissions they have. Users only have those permissions while they are assigned to a particular role; should they be removed from a role, the associated permissions would also be revoked. This makes it possible to quickly and holistically manage permissions for each user with that role.
Role-role relationships: Permissions can also be restricted based on the combination of roles a user may have. For example, a staff accountant in North America at a global company may have both the Staff Accountant role, and also the North America Employee role. The combination of these two roles will result in the staff accountant only having access to records related to North America.

RBAC should be flexible enough to allow an organization to define roles as it sees fit, and also define any constraints or rules related to those roles. Common constraints include limiting permissions based on a specific project, setting a time limit or expiration date, applying permissions based on physical geographic location, or limiting permissions by the time of day.

RBAC is accepted as a best practice. NIST and ANSI / INCITS have all defined standardized approaches to its use and implementation, including what is included in core RBAC, the rules of inheritance between roles, and how it can be used to enforce separation of duties through constraints.

Modern security solutions have emerged to help you take advantage of RBAC.

Implementing RBAC can be challenging for diverse, growing organizations to implement consistently. There are ways to make it easier.

Enterprise environments are complex, with a diverse set of use cases that make it difficult to implement RBAC for all systems, users, and scenarios. Fortunately, modern security solutions have emerged to help you take advantage of RBAC for a consistent security approach that covers new use cases.

Want to stay ahead of cybersecurity challenges by following the top InfoSec pros?
Then add these 10 cybersecurity experts to your watch list.

FREE EBOOK
Privileged Access Management For Dummies

Download Ebook

How does RBAC manage overlapping role assignments?

RBAC utilizes an additive model, in which a user’s permissions become the union of all their roles. In cases where a user has multiple roles, an administrator should configure how RBAC is applied, so any conflicts between roles are addressed and a user doesn’t end up with more permissions than intended. This is one way that organizations can ensure the separation of duties.

There are two main types of separation of duty policies in RBAC—Static (SSoD) and Dynamic SoD (DSoD). Mutually exclusive role constraints are used to enforce static separation of duty policies, while dynamic separation of duty policies are intended to limit the permissions that are available to a user.

To further codify permission assignment and inheritance, NIST has specified four levels that define groups: flat, hierarchical, constrained, and symmetric.

Flat: Users acquire permissions by being assigned to roles and the user is granted the permissions associated directly with their role. For example, there may be a single, comprehensive role called “Admin” assigned to all users who need admin permissions.
Hierarchical: Through tiers and relative role relationships, a permission hierarchy can be defined, along with associated rules of how those permissions are inherited, such as for enterprise admins vs. domain admins.
Constrained: To enforce separation of duties, depending on the roles a user is assigned, they may be limited to only performing certain actions based on which systems or applications they are using.
Symmetric: Organizations use this approach to maintain consistent standards. Objects, roles, and permissions available must be exactly the same across every system and application regardless of where they are deployed. For example, a system administrator role within an application in North America would have the same permissions available as one operating in EMEA within the same application.

How do companies use RBAC?

RBAC makes it simple for companies to create, assign and update user permissions, due to the role-role, user-role, and role-permission model.

RBAC simplifies common IT admin tasks like onboarding a new user, moving someone to a different department or division, or, most importantly, off-boarding a user.
RBAC allows you to quickly modify permissions in bulk—for all users with a particular role—either to grant them additional access, tweak their permissions based on new or obsolete resources, or lock down their permissions, especially important in the event of a breach.
Users themselves are never directly given permission. Permission only comes along as part of their role. Therefore, if a user’s role changes, it’s straightforward to update their permissions by modifying their role. Any resources they had access to with one role are not retained unless they’re also explicitly a part of the new role. This prevents permission creep.
When systematically applied, RBAC reduces the risk that a user will be granted too much access. With clearly defined roles, you can establish protocols detailing exactly which role is appropriate for each type of user. By creating appropriate roles, it’s possible to prevent or mitigate inappropriate permission inheritance.

What are some alternatives to RBAC?

While RBAC is widely accepted as an industry standard and best practice, there are other approaches to permission and access control, each of which may be advantageous in specific situations. Some of these models evolved from RBAC.

Access control lists (ACLs): An access control list is a set of permissions applied directly to an object. While RBAC systems manage permissions across users, ACLs are specific to an object, such as a database or file. ACL can be used to define access and authentication permissions, while RBAC defines which resources and actions a user can take once authenticated.
For example, when someone is given access to an office building, that is granting them entry. Once they are inside, however, they may not have permission to speak to others or answer any ringing phones.
- Pro: Granular, object-level control
- Con: difficult to administer at scale and maintain over time, difficult to enforce separation of duties (SoD), resource owner could set individual permissions
Attribute-based access control (ABAC): This model, also known as policy-based access control, is based on RBAC, yet rather than relying on static permissions, it relies on logic-driven policies to define in-context permissions. Policies can be static or driven by pre-determined formulas and logic. ABAC implementations include additional attributes for users (citizenship, clearance, etc.), resources (classification, department, owner, etc.), actions, and context (time, location, IP, etc.).
- Pro: Provides dynamic flexibility based on context
- Con: More complicated to configure and maintain

Additional models include capability-based security, location-based authentication, and risk-based authentication.

RBAC and Active Directory

For organizations already managing permissions via Active Directory (AD) and similar tools, RBAC is a natural fit; user groups often map naturally to user roles.

Implementing RBAC via a hub and spoke model, where Active Directory or another central directory is the hub, allows for a unified view and centralized consistent control.

How to start or improve an RBAC implementation

To set up an RBAC system, you must:

Inventory systems: Create a comprehensive list of every server, database, application, external website, etc. that users might need access to. Optionally, include physical security in this list, covering access to server rooms or other sensitive physical spaces and resources. Create a map of who (or what) currently has access to those systems and resources.
Create roles that reflect your organization: Assess current usage patterns throughout your organization and create roles that align with them. Consider when and whether to use hierarchical or constrained RBAC (e.g. determining when to have permission inheritance between roles, vs. enforcing separation of duties). Determine whether to create roles that align with current usage or use newly defined roles to reflect how your organization aspires to work.
Ensure that roles are aligned with the work that people in that role need to get done so that the roles don’t need to be modified frequently. Don’t forget to create roles for contractors or other third-party users who may need temporary or restricted access and roles for non-human service accounts. As a general rule, create the least amount of access a user or role needs to get their job done and limit the time they have access to perform the tasks.
Articulate the RBAC policy: Document the implemented RBAC policy, even if you’re using an automated tool to implement it. Many compliance schemes require access control policies to be thoroughly documented, and to have that documentation undergo a change control process to ensure it remains current. Then, extend that governance to include RBAC within each ap With the shift to cloud infrastructures, SaaS applications, and the convenience of SSO, users and groups commonly inherit roles with excessive permissions. RBAC helps to mitigate this risk.
Assign people and accounts to roles: Pragmatically assign users to roles that match their job function, prescribing access with least privilege in mind, and resist pressure to provide users with more access than they need. Implement granular access approval controls that include auditable logs to govern just-in-time access requests.
Audit regularly: Conduct periodic reviews to ensure users are assigned to proper roles (since roles can change over time) and each role has appropriate permissions. Don’t make one-off changes for one employee to satisfy their unique needs. Either update permissions for their role or create a new role as appropriate. Doing so will enable you to manage the system over the long haul.

RBAC, Compliance, and Audits

Many national and industry-specific compliance bodies specifically call out RBAC as a requirement. Want to pass your audit? Polish your RBAC. You need to be able to prove—via reports and other evidence—that all IT systems across the enterprise meet these RBAC compliance requirements.

Check out the documents linked below for a more detailed look at how RBAC maps to different compliance schemes.

HIPAA, the Health Insurance Portability and Accountability Act, mandates how organizations that handle Personal Health Information (PHI) must protect it.
The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle major branded credit cards. PCI DSS provides organizations that accept, store or transmit credit card data with guidelines and a framework to protect cardholder data. Financial institutions, online retailers, and tech companies developing apps and tools that serve online businesses must meet PCI standards and validate their compliance each year.
NIST/FISMA: To protect sensitive data and mission-critical systems from cyber attacks, the Federal Information Security Management Act (FISMA) mandates that Federal agencies and government contractors develop, document, and implement a security program, as documented in NIST SP 800-53.
SOX: The Sarbanes-Oxley Act was created to provide accuracy and transparency in financial disclosure, and to establish internal controls for all organizations dealing with public funds.
ISO 27001 Controls: This standard helps organizations implement an Information Security Management System which “preserves the confidentiality, integrity, and availability of information by applying a risk management process and gives confidence to interested parties that risks are adequately managed.”
The Center for Internet Security (CIS) created a framework of Critical Security Controls (CSC) to help organizations answer fundamental questions like How do we prevent security breaches? What does that mean for our organization? What should I be looking for or doing when securing our network?
The National Credit Union Administration (NCUA) requires that credit unions audit their cybersecurity practices to assess the level of risk in accordance with the U.S. Code of Federal Regulations, Part 748.
The National Cyber Security Centre in the United Kingdom developed the Cyber Essentials program to ensure that every organization, particularly those seeking government contracts, has basic cybersecurity controls in place. Contractors in the UK that handle sensitive or personal information must receive Cyber Essentials Certification to demonstrate understanding and enforcement of their cybersecurity responsibilities.
The United Arab Emirates (UAE) Information Assurance Standards (IAS), administered by the National Electronic Security Authority (NESA), are designed to improve cybersecurity efficiency and effectiveness for government entities and businesses across all of the UAE that deal with information and communication infrastructure.

RBAC and Unix/Linux

Every Unix server, and its open-source cousin Linux, has a local database of users and groups. If you have a single host with one user, there’s no problem with management. But, when you have multiple servers, a single user becomes multiple and it’s very easy to start mixing things up and create a mess.

There are different usernames, UID’s, PGID’s, GID’s, home directories, login shells, and, of course, passwords on each system. In addition, users, even admins, still log in as root or can easily elevate their privileges to perform tasks and make changes. With a user’s attributes tied so tightly to the file and folder permissions on a Unix host, which hasn’t changed much since the early days of Unix, user, group, and permission management quickly becomes a tedious and time-consuming task.

Secret Server allows you to centrally discover, rotate, expire, and disable credentials as part of a comprehensive strategy for Privileged Access Management.

SSH keys are critical to maintaining secure communication with, and access to manage servers and appliances, yet most organizations are lax in how they control key generation, where they are installed, what access they grant, and even how many different admins reuse and share them with colleagues.

You can use Secret Server and Connection Manager to limit SSH key proliferation and closely manage what access each key provides. These solutions allow you to set limits on what commands can be run based on the key that is connecting.

RBAC, cloud vendors, and third-party apps. Cloud infrastructures like Amazon Web Services, have their own RBAC configurations. Third-party applications may not include granular permissions, preventing symmetry between internal and external policies. For example, they may not allow you to create different levels of administrators with different permissions, such as adding or editing a resource, but not deleting it.

Relying on these systems can lead to variability in permission levels and roles and make auditing and tracking each user and their access tricky. To mitigate this disconnect, you can put controls and policies in place governing who has access to perform which actions for third-party platforms and applications.

RBAC isn’t limited to the IT organization any longer; now the brand of an organization is controlled by social media. And those social media accounts, with the privileges to post and share as an official organization representative, are typically managed by non-IT departments. It’s imperative to govern precisely who, when, and what those accounts can do to reduce the risk of compromise.

Remote Access Service (RAS) in the Delinea Platform allows IT teams to manage policy-based access controls through a central portal with concurrent licensing to support every environment. RAS eliminates the need for a jump host or an agent either on the user’s machine or the target server. By using only a browser, you can establish secure connections via RDP to Windows servers and SSH to Linux servers and network devices. To ensure oversight and compliance, you can audit remote access sessions through scheduled or on-demand activity reports

RBAC and Service Accounts. Service accounts, or non-human privileged accounts, are often excluded—either intentionally or accidentally—when RBAC is implemented. Organizations blindly trust these accounts because once implemented, there’s a fear of an outage because it’s a challenge to confidently identify all dependent services.

As a result, service and application passwords are often set to never expire and keep the same password for years. Not changing service account passwords represents a significant security risk as these accounts often have ungoverned access to sensitive data and systems

With service account discovery and management, Secret Server automatically scans for applications using a service account on the network and can automatically link up dependent services and applications.
You can administer service accounts via Account Lifecycle Manager in order to include them in your security strategy. A comprehensive Privileged Access Management (PAM) solution lets you authenticate users, assign privileges, and create an audit trail. By bringing both human and non-human privileged accounts under a common PAM umbrella, you can prevent misuse and cyber attacks.

Measurable benefits of role-based access control

RBAC is the very definition of a systematic, repeatable process. Predefined roles mean fewer mistakes: When roles and permissions are preconfigured, there is less opportunity for human error which might arise with manually having to configure each user. The chance of inadvertently giving users access to restricted resources is much less common when using RBAC.

Audit reporting is much faster. A single, logically implemented system configured using the right tools means that administrators can quickly summarize access, look for anomalies, and ensure compliance with existing policies.

All of the above results in IT spending less administrative time granting and revoking access and less time monitoring user behavior and creating reports. They have more time available for high-value, strategic tasks. The increased efficiency associated with RBAC can have a measurable benefit on your profitability, productivity, and capacity for innovation.