- Role-based, attribute-based, & just-in-time access to infrastructure
- Connect any person or service to any infrastructure, anywhere
- Logging like you've never seen
Summary: This article presents an overview of RBAC vs. ABAC, plus several additional models of access control, including PBAC, ACL, and DAC. You will learn what these methods are, how they differ from each other, and the pros and cons of each. This knowledge will help you choose the best-fit access control model for your organization so you can start on the path to implementation with confidence. Let’s dive in.
What is RBAC?
Role-based access control (RBAC) is a security approach that authorizes and restricts system access to users based on their role(s) within an organization. This method allows users to access the data and applications needed to fulfill their job requirements and minimizes the risk of unauthorized employees accessing sensitive information or performing unauthorized tasks. In addition to restricting access, RBAC can define how a user interacts with data—permitting read-only or read/write access to certain roles, thus limiting a user’s ability to execute commands or delete information.
Benefits of RBAC include:
- Security. RBAC uses the principle of least privilege to lower the risk of a data breach. It also limits damage should a breach occur.
- Ease of Use. RBAC connects employees to the data and systems they need and reduces administrative overhead for IT.
- Compliance Readiness. Administrators can more easily prove that data and sensitive information have been handled according to privacy, security, and confidentiality standards.
However, implementing RBAC requires collaboration across departments. Determining how to categorize roles and manage access for those roles requires a clear understanding of both the business and the technical infrastructure that supports it. Assigning roles can be a challenge, especially as organizations grow and change. Admins may assign people to ill-fitted roles or add new roles contrary to policy, leading to privilege creep, role explosion, and security gaps.
✨ Make it Easy: Implementing RBAC is arduous, but StrongDM makes it simple. Just define your roles directly in StrongDM or leverage roles in your identity provider (IdP). With your IdP, use StrongDM’s SCIM integration to easily sync user and group permissions. Need to offboard an employee? The change in your IdP is reflected in StrongDM right away.
⚠️ Traditional PAM deployments have gaps. Learn how to protect your databases, the cloud, Kubernetes, and more with our legacy PAM augmentation guide.
What is ABAC?
The difference between RBAC and ABAC stems from the way each method manages access. Unlike RBAC, which grants access according to predefined roles, ABAC is a security policy that relies on a combination of attributes to match users with the resources they need to do a job.
Attributes may consist of:
- user demographics include name, organization, job title, or security clearance.
- resource properties such as owner, creation date, or file type.
- environmental specifics such as time of day, location of access, and threat levels.
By evaluating attributes of both subjects and resources, ABAC allows for more flexibility in policy creation and enforcement. With ABAC, access is dynamic. Decisions can be made according to context and risk at runtime. ABAC policies can be enforced on servers, databases, clusters, and a host of other resources.
Key benefits of ABAC include:
- Granularity. Because it uses attributes rather than roles to specify relationships between users and resources, administrators can create precisely targeted rules without needing to create additional roles.
- Control. With ABAC, data teams can restrict access to personally identifiable information (PII) using tags. In the healthcare field, for example, administrators can connect tags to HIPAA privacy standards to automatically separate those who have access from those who don’t.
- Flexibility. ABAC policies are easy to adapt as resources and users change. Rather than modifying rules or creating new roles, admins need only assign the relevant attributes to new users or resources.
- Adaptability. ABAC makes adding and revoking permissions easier by allowing admins to modify attributes. This simplifies onboarding and offboarding as well as the temporary provisioning of contractors and external partners.
- Security. ABAC allows admins to create context-sensitive rules as security needs arise so they can more easily protect user privacy and adhere to compliance requirements—without requiring a high degree of technical knowledge.
However, ABAC, whether stand-alone or as part of an RBAC and ABAC hybrid approach, takes time, effort, and resources to implement. Teams must define attributes, assign them to users and objects, and generate rules to govern the attributes and their application.
With both RBAC and ABAC, data teams have fine-grain access control, giving them even more security and productivity benefits. These controls can be assigned based on specific attributes, characteristics, and conditions to severely limit the viewing and use of sensitive data.
For example, a security administrator can limit users from accessing specific rows on a table that contain location data that is outside the user’s region of responsibility. They can also mask data like social security numbers or employee salaries, or remove data access altogether outside specific working hours.
What is PBAC?
Policy-Based Access Control (PBAC) is another access management strategy that focuses on authorization. Whereas RBAC restricts user access based on static roles, PBAC determines access privileges dynamically based on rules and policies. Although PBAC is fairly similar to ABAC, ABAC requires more IT and development resources (e.g., XML coding) as the number of required attributes increases.
Some key benefits of PBAC include the following:
- Flexibility. Admins can generate policies that allow access to be fine- or coarse-grained.
- Speed. PBAC lets you quickly add, remove, or amend permissions.
- Adaptability. Policies address environmental and contextual controls (e.g., time- or location-bound access).
- Observability. Human-readable policies provide visibility into the relationship between identities and resources.
- Compliance. Align internal policies dynamically with access controls to ensure the organization is consistently in compliance.
These benefits may make policy-based access control more adaptable than some alternatives, especially as organizations grow and change. But every access control system will require some amount of management and thoughtful implementation. PBAC is no exception.
What is ACL?
Access control lists (ACLs) control or restrict the flow of traffic through a digital environment. ACL rules grant or deny access in two general categories:
- Filesystem ACLs apply to files and/or directories. The ACL specifies which subject (human user or machine/system process) is allowed access to objects and what operations are allowed on those objects.
- Networking ACLs apply to the network routers and switches. The ACL specifies which type of traffic can access the network and what activity is allowed.
Organizations use ACLs in tandem with VPNs to manage traffic. Doing so may improve network performance, increase security, and allow for more granular monitoring at entry and exit points. This makes ACLs suitable for securing individual users and low-level data, but it may not be the best approach to access management in most business applications.
What is DAC?
Whereas RBAC, also known as non-discretionary access control, takes a more human-level approach to control access, Discretionary Access Control (DAC) uses ACLs to restrict access to resources, such as files and database tables, and define which privileges a user has for that resource.
With DAC, each user controls access to their own data. This method decentralizes security decisions, allowing resource owners to grant or restrict access as they see fit.
The primary benefits of DAC include the following:
- Simplicity. As long as a user and their privilege are correctly listed in an ACL, they can access the resource.
- Flexibility. Because access control is decentralized, resource owners may grant and revoke access to resources without going up the chain of command, allowing them to make decisions quickly.
- Granularity. The data owner can add or remove access based on individual needs.
For larger or more complex organizations, however, the simplicity and decentralization of DAC can also lead to problems. With DAC, security administrators may not have a clear mapping of how resources are accessed and interconnected throughout the network, particularly as changes to that access occur. This may lead to over-privileged users and conflicting permissions, which in turn compromise security.
Combine the Strengths of RBAC and ABAC
Although ABAC is not necessarily a superset of RBAC—the two models can function independently—uniting attribute- and role-based access control helps DevOps teams achieve greater speed and flexibility, especially as environments become increasingly ephemeral.
StrongDM combines the strengths of RBAC and ABAC, allowing businesses to enforce either role- or attribute-based access controls. Administrators can use static access rules (RBAC) to assign access to a specific resource(s) to a role. And they can use dynamic access rules (ABAC) to establish and enforce access rules based on granular attributes, including tags, resource types, and geographic location. This fine-grain access control keeps security tight and data out of the wrong hands.
Access is granted dynamically, based on a resource’s attributes, not the specific physical resource, so roles and users maintain just-right access every time a resource gets spun up or torn down. This flexibility is particularly useful for companies with lots of resources on the backend, especially ephemeral ones.
Benefits of StrongDM’s dynamic access rules:
- Precise Control. Administrators can set conditional access controls based on any criteria they choose, make connections and relations between systems and users, and have granular, context-aware control over access to file system resources.
- Ease of use. Human words and simple sentences create access rules that dynamically change when resources change making access rules easier to enforce and quicker to implement.
- Time sensitivity. Administrators can temporarily approve elevated privileges for sensitive operations, reducing risk by putting time limits on higher levels of access.
- Better workflows. Dynamic access rules reduce administrative busywork, giving you more control when provisioning infrastructure and making it easier for staff to access the resources they need.
- Flexibility. By basing access rules on tags, StrongDM helps you keep pace with the ephemerality of today’s computing landscape.
Managing access in the modern cloud presents new challenges for your organization. Ephemeral infrastructure and fast-paced production environments demand an access control model that balances accessibility with security. RBAC and ABAC, as well as their alternatives, each, come with pros and cons, and understanding them will help you choose the right access control model for your organization. While any implementation will come with startup costs, the effort you put in today will yield great benefits in the long run.
Want to simplify the way your teams access infrastructure? StrongDM is here to help. Sign up for our no-BS demo and see for yourself.
About the Author
Maile McCarthy, Contributing Writer and Illustrator, has a passion for helping people bring their ideas to life through web and book illustration, writing, and animation. In recent years, her work has focused on researching the context and differentiation of technical products and relaying that understanding through appealing and vibrant language and images. She holds a B.A. in Philosophy from the University of California, Berkeley. To contact Maile, visit her on LinkedIn.