ABAC terminology
Understanding the following terms will help understand how ABAC works.
Attributes
Attributes are name-value pairs assigned to the ABAC system’s three elements: subjects, objects, and environmental conditions. Attribute values describe some characteristic of the ABAC element and can be any data type.
Objects
Objects are the datasets, networks, or other information systems the ABAC system protects. Object attributes, also called resource attributes could include creation date, country of data residency, or personally identifiable information.
Subjects
Subjects are the individuals or non-person entities trying to access the protected object. Subject attributes, sometimes called user attributes, could include security clearance, job title, or workplace country.
Environmental conditions
Environmental conditions are any criteria not specific to objects or subjects. Environmental attributes could include time of day, threat level, or network bandwidth.
Operations
Operations are the actions subjects are allowed to perform within the context of the ABAC-granted permissions.
Access policies and rules
An ABAC policy is a human-readable definition of the circumstances under which the system will grant or deny access to an object. Access policies get translated into machine-readable access control rules that evaluate object, subject, and environmental attributes.
How does ABAC work?
ABAC solutions manage access to protected resources by evaluating in real-time the complex combinations of rules generated as subjects request access to objects. Planning is essential to successful ABAC implementation. Architects must pay careful attention to defining attributes, developing policies, and creating the rules to manage access to sensitive or protected information. Once implemented, automated workflows ensure rapid access decisions.
Creating attributes
Just as rich metadata is essential to making data discoverable and retrievable, rich attribute sets are essential to a robust ABAC system. They allow the system to implement policies at a more granular level. However, asking the system to evaluate too many attributes could delay the final decision.
Implementation teams must address the tension between centralized and distributed responsibilities within the enterprise. Assigning attribute management to a central data team helps ensure consistency across the organization, but at the expense of flexibility and domain awareness. Pushing the responsibility outwards will result in attributes that reflect on-the-ground business needs at the risk of inconsistencies that could leave data unprotected.
Authorization policies and rules
Policy management faces a similar tension. Companies must decide who is responsible for developing and managing authorization policies and ensuring the resulting ABAC rules correctly implement those policies.
These rules combine multiple Boolean operations to determine whether an access request meets the threshold for authorization and what operations the subject may perform under that authorization.
Because it evaluates multiple attributes, the ABAC authorization model can be context-aware. Remote users on a public network may receive different level of access than when they are on the company’s private network. Human resources managers in the United States may only see aggregated data about European employees while their counterparts in Europe may see individual employee records.
Benefits of ABAC and use cases: Why is ABAC important?
The ABAC model addresses a critical need of large enterprises with complex, dynamic organizational structures — how to manage access when the relationship between users and data resources constantly changes? ABAC lets data security teams develop fine-grained access policies to address varied use cases, including:
Data protection: ABAC is an effective way to create cybersecurity and access policies based on the principle of least privilege, authorizing people or systems to access the data they need to do their work.
Regulatory compliance: Enterprises must be able to use their data while complying with a patchwork of regional and national data privacy regulations. ABAC systems can use attributes like data and user location to decide what permissions to grant under any regulatory regime.
Operational efficiency: In organizations with thousands of users and complex data architectures, constant change can overwhelm data security teams and create data security risks. ABAC automates policy enforcement, providing a level of scalability that other access control models lack.
Team collaboration: Enterprises depend on cross-functional teams with fluid membership that must collaborate across internal and external boundaries. More rigid access management approaches can prevent these teams from working effectively. Simply assigning a team attribute to new users will grant those participants access to the team’s resources.
The benefits of ABAC versus traditional access control models has led to its growing adoption by enterprises.
ABAC vs ACL (Access control lists)
Access control lists define specific criteria for granting or denying access to an object. Each object gets its own ACL which the security team must maintain. In a large enterprise, that management task quickly balloons. Any change requires discovering which ACLs are impacted, modifying the relevant lists, and provisioning hundreds or thousands of lists across the organization’s infrastructure.
ABAC is much more resilient in the face of change. Modifying one attribute ensures the change takes effect system wide.
ABAC vs IBAC (Identity-based access control)
An early form of access control defined permissions for each user. Once an authentication process confirmed the user’s identity, that person could access the requested resources.
However, identity-based access control imposes considerable overhead since someone must revoke old access privileges as users’ responsibilities change. This basic security measure too often falls through the cracks when managing access for thousands of employees. As a result, people collect access privileges throughout their career, increasing the risk that their compromised credentials lead to a security breach.
ABAC recognizes that secure access is about more than identity management and must include criteria based on the accessed resource and the environment in which the access takes place.
ABAC vs RBAC (Role-based access control)
Role-based access control addressed some of the management issues of identity-based models. Rather than assigning permissions to each user, RBAC assigns permissions to groups of users based on their roles in the organization.
User roles may be hierarchical with supervisors, managers, and executives getting progressively higher levels of access. User roles could also be functional — for example, distinguishing user roles for creating and approving transactions.
RBAC systems can be easier to manage than identity-based systems. A new employee is simply added to their new role to get access to the systems and data they need for their work.
In a way, RBAC is a subset of ABAC that only considers the subject’s role attributes. That limited decision space means role-based systems are not as contextual as fully attribute-based systems that can evaluate many more criteria.
ABAC vs PAM (Privileged Access Management)
Privileged users’ compromised credentials are among the most dangerous vectors for cyberattacks. By definition, these users have permission to access and change critical systems hackers can use to escalate their attacks. Companies layer PAM systems on top of their normal identity and access management (IAM) systems to provide an extra level of security.
ABAC solutions unify access management within a single system. Subject attributes can define users’ privileged status. At the same time, object attributes can identify actions available to privileged users. Combined with environmental attributes, an ABAC system can enforce policies that dictate how privileged users may access critical resources.
Data security: How do you implement attribute-based access control in a cloud environment?
Starburst Galaxy’s modern data lakehouse analytics platform enables attribute-based access control for catalogs, schemas, tables, views, and columns which, when combined with user roles, allows companies to implement fine-grained access policies for every enterprise data source.
Administrators can activate ABAC in Starburst Galaxy by assigning tags to the various levels in the data hierarchy. They then create attribute-based policies within relevant user roles by creating Boolean expressions based on the data object tags.
Check out our free hands-on tutorial to learn how ABAC works in Starburst Galaxy.
