A critical component to securing organizational data is limiting unnecessary access to resources. By enforcing the principle of least privilege (whereby users are granted only the minimum level of access needed to effectively perform their job), companies can contain and minimize the risk of credentials-based attacks, and can better maintain compliance with industry and governmental regulations.
When threat actors leverage stolen credentials to access an enterprise ecosystem, the damage they can inflict is limited to the access those credentials allow. Excess privilege is an accelerant for these attacks, and can dramatically multiply the damage and devastation from a data breach. The Home Depot and Target, to choose two recent high profile attacks, suffered data breaches when a third-party vendor’s credentials were compromised, giving hackers exploitable nontrivial access to their networks.
Clearly, the principle of least privilege is a critical tool for enterprise security. But keeping a tight rein on data access in a complex modern organization, with shifting roles, departments, and employee status, is hard to do at scale. Two viable methods to enforce the principle of least privilege at scale have emerged: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). The difference between RBAC and ABAC, in a nutshell:
The RBAC approach was introduced by the U.S. National Institutes of Standards and Technology as a better, more scalable alternative to discretionary access control (DAC), where each resource’s owner establishes that resource’s access rules. RBAC takes a more holistic view, granting access based on each user’s defined role and its functions. An entry level marketing employee would have very different access levels than an IT or security team manager, and those access levels would apply to anybody in that role, independent of their identity—permissions can flow automatically to any new hires once they’re assigned to particular roles.
The ABAC approach is a little more complex. Instead of relying on roles, ABAC’s access policies consider multiple factors, with granular permissions ultimately determined by three broad sets of attributes: those around the user, the data, and the environment. Access to certain general data could be granted by virtue of a user’s job title or department. A set of sensitive files might require elevated access, regardless of any individual user’s role. And system restrictions might prevent access to an embargoed dataset for everybody until after an earnings report or announcement occurs, no matter what other access parameters apply.
Here’s a little more detail around the two approaches.
What is Role-Based Access Control (RBAC)?
With the Role-Based Access Control approach, roles are defined based on groups of users and potential users who share certain characteristics, like departments, office locations, seniority levels, or work duties. For example, users within an accounting department might be given role-based access to certain financial data that other departments don’t need.
Once roles have been defined (at whatever level of granularity is required), each role’s permissions can be specified at three basic levels: Access, operations, and sessions. Access permissions determine what the user is allowed to see—a junior associate in finance doesn’t even need to read the names of the folders in a tech department server, never mind the data in the folders. Operations permissions determine what each user is allowed to read, write, update, and delete. Seniority often comes into play here, with only more senior employees granted a higher level of permissions (for example: the power to delete an important file). Finally, Sessions permissions acts a parameter that determines how long a user is allowed to stay in the system—another way to limit potential nefarious activities.
RBAC can be enforced across four major subtypes, adding more flexibility:
(Level 1)
• Flat: The simplest level of permissioning, determined solely by employee role.
(Level 2)
• Hierarchical: All Level 1 permissions, plus expanded permissions for senior employees.
(Level 3)
• Constrained: All Level 2 permissions, plus separation of duties in role permissions.
(Level 4)
• Symmetrical: All Level 3 permissions, plus periodic role permissions review.
The Benefits of RBAC
As a systematic approach, RBAC is simple to establish and maintain, and it scales well, unlike its DAC (dynamic access control) predecessor. Roles can be easily defined, often based on the company organization chart, enabling consistent, automated access based on the principle of least privilege. RBAC accelerates onboarding by automatically assigning role-based access to new employees and enabling quick reassignments of permissions at a global level, across platforms and applications. External users like vendors and business partners can themselves have pre-defined role-based accesslimitations, helping to mitigates third-party risk. It all speeds time to value for new hires and acquisitions, and can save significant time and money.
The Drawbacks of RBAC
RBAC’s easy provisioning and deprovisioning can work wonders for a smaller organization. But creating hundreds of thousands of roles for a large and complex enterprise is a daunting challenge, and many enterprises find themselves outgrowing RBAC as business expands. Other challenges:
Coarse access control. In some cases, RBAC’s simplicity can make it difficult to enforce the principle of least privilege. An employee working in a brand-new division inside accounts payable, for example, might inherit access to payroll data that isn’t relevant to their job.
Role explosion. Organizations that find they require more granularity in their roles than originally expected may start to create multiple new roles within the system, which costs additional time and can proliferate into hundreds or thousands of roles to monitor.
Managing technical debt. Companies can grow and morph in unpredictable ways, meaning the upfront policies demanded by the RBAC system must be manually retrofitted as things change. When a U.S. company expands its operations to the EU, for example, they may have to redefine existing policies to ensure relevant RBAC roles are GDPR compliant.
What is Attribute-Based Access Control (ABAC)?
ABAC grants access based on a combination of user, resource, and environment attributes. Specific combinations of these factors determine permissions, adding flexibility that enables management to adhere even more tightly to the principle of least privilege. Here’s how the three attribute areas contribute to permissions:
• User. User attributes can include job title, seniority level, typical workload, and other factors that might logically limit what any individual user ought to be able to see and access.
• Resource. Resource attributes come from the data itself, including file type, sensitivity, data creator, and other important considerations that can define a data asset’s access restrictions.
• Environment. Environmental attributes give admins a third dimension for access restrictions, including location, time of day, IP address, and device type.
The ABAC model lets enterprises safely automate more concise decisions within the continually changing reality of business operations, rather than having to rely on static “set it and forget it” IT rules. Administrators can define a safer, more flexible level of access by triangulating the subject (who exactly is requesting the access?), the object (what resources are being requested?), and the operation (what does this person seem to be trying to accomplish?)
The Benefits of ABAC
The ABAC approach lets companies scale more easily than RBAC. More granular control over access rules permits ABAC admins to express richer, more complex access policies and to update them more easily, updating business attributes instead of creating new roles for every eventuality. This lets enterprises more tightly enforce the principle of least privilege, even as they grow and scale. Using the example of an American business expanding operations to Europe, the ABAC system would let the company simply update data access rules with a new user location restriction.
The Drawbacks of ABAC
The main downside of the ABAC approach is that while the process is easier to adjust and enforce down the line, its initial setup is much more complex, and an ABAC system can be extremely time consuming to set up and kick off. Hundreds of thousands of attributes need to be defined around all the system’s users, resources, and environments. And developing the initial policy set covering all of these cases so it can be safely automated—and making sure all of the proposed permissions align with policy as expected, and finding and fixing misconfigurations after launch—is a monumental task.
RBAC vs. ABAC: Use Cases for Both Solutions
So which data access control implementation approach is the winner? It depends on the specifics of your business. A simply-structured enterprise with a small number of employees is likely better off sticking with the straightforwardness and ease of setup that RBAC provides. Large or complex businesses, or ones who often deal with time-sensitive or embargoed data like product launches or earnings releases, might find ABAC a better choice. For a global company in a heavily regulated industry required to comply with the GDPR’s strict rules around how personal data of EU citizens is stored, processed, and exported, an ABAC access policy might be the best choice, for example, to easily stay on top of complex data access control variables.
Generally speaking, role-based RBAC is best for coarse, simple solutions, while ABAC’s variable dependency is ideal wherever more fine-grained control is needed. But with pros and cons to both approaches, many organizations in practice use a hybrid system, using RBAC controls to grant high-level access, then governing detailed access controls with ABAC. Administrators could for example use an RBAC system to hide sensitive data from junior employees, and then use an ABAC system to fine-tune senior employees’ access to that data and decide who specifically can read, write, add, and delete those documents. Whether used separately or together, RBAC and ABAC are both highly effective ways to manage, automate, and enforce data access permissions at scale.
How do I make Access Controls a Priority for my Organization? Introducing Veza.
At Veza, our mission is to help organizations trust confidently, so they can unlock the value of their data. Our data security platform built on the power of authorization enables companies to efficiently secure their cloud data systems through comprehensive visibility and management over data access permissions across all identities, human and non-human. We provide organizations the ability to streamline the management of key data security initiatives across privileged access, data lake governance, entitlement management, and more.
To learn more about incorporating Veza into your data security initiatives, check out our Core Authorization Platform.
