What is Attribute-Based Access Control (ABAC)?

Attribute-based access control (ABAC) is an approach to security that considers the attributes that belong to the entities and resources of an access request, to allow or deny the request. An attribute is a fact about someone or something, an entity is a human or machine that requires access to a secured resource, and a request is an action that the entity is attempting to take on the resource.

ABAC is an advanced and powerful technique that can implement the most complicated and dynamic access patterns that are seen as organizations grow and scale, especially in the cloud. This means that security teams should be aware of, and consider using, ABAC to manage their access, while still being aware of the trade-offs and challenges associated with it.

Types of attributes

Policies in an ABAC system are evaluated in the context of the attributes, not the roles of the entities involved. Attributes represent facts that come in different broad categories: immutable, mutable, and inherited. Immutable attributes cannot be changed, such as the time of the request, or the type of resource being accessed. Mutable attributes can be changed, and likely will over time, such as on-call status and team membership. Inherited attributes represent relationships, such as membership of a group or business unit.

Some attributes are immutable, but can change over time, such as the IP address associated with an entity. Even though these attributes change, they’re not controlled by the entity making the request. Other aspects of the request, such as the action being taken on the resource like reading or writing, are controlled by the entity. Often attributes will be inherited or provided by the organization’s identity provider (IdP), which makes it easier to manage attributes at scale.

Both the entity making the request, and the resource being accessed by the request have attributes. All the various sources of attributes come together to form the security context of a request, so that it can be allowed or denied by the access management engine.

An example

Consider a common cloud-based scenario: an engineer needs to access a production database to troubleshoot an urgent issue or incident.

In this scenario, the important components of the request are:

1. The engineer (the entity requesting access)
2. The production database (the resource being accessed)
3. The action (read and write access to the database)
4. The context of the request (time of day, the engineer's location, etc.)

The organization has the following security policy: Engineers can access production databases only if they are on-call, and accessing from a secure location.

In an ABAC system, this policy would be implemented using various attributes:

• User attributes:
  • Role: Engineer
  • On-call status: Yes/No
• Resource attributes:
  • Type: Database
  • Environment: Production
• Context attributes:
  • Location of access

When the engineer attempts to access the database, the access management engine would evaluate these attributes:

1. Is the entity’s type "Engineer"?
2. Is the user currently on-call?
3. Is the resource in the production environment?
4. Is the resource a database?
5. Is the access attempt from a secure location?

Only if all these conditions are met would the engine allow the request. This approach allows for fine-grained control, for example:

• An engineer that is not on-call wouldn't get access, even if they meet the other requirements.
• Access would be denied if attempted from an unsecured location, regardless of other factors.

Contrast this with a simpler Role-Based Access Control (RBAC) approach, where an engineer might have permanent access to all databases, regardless of on-call status or the presence of an active incident. ABAC provides a more dynamic and context-aware security model, particularly valuable in cloud environments where resources and access needs can change rapidly.

Benefits of ABAC

Some of the benefit this provides includes:

• Flexible and fine-grained controls. Policies that combine checks of multiple attributes enable a much tighter level of control compared to other approaches.
• Fewer policies required. ABAC can often meet complex access requirements with fewer and smaller policies compared to techniques that don't use attributes.
• Easily support dynamic environments. Since attributes reflect the facts about an entity and resource, changes only impact the resources that are involved, and policy changes are usually not required in normal or business-as-usual scenarios. For example, moving entities between teams is as simple as updating their team attribute.

Ultimately, ABAC allows you to make more context-aware and fine-grained access decisions in real time.

Challenges

Unfortunately ABAC doesn’t solve all access problems, and it comes with trade-offs like any approach:

• Increased complexity. The flexibility and dynamic capability comes at the cost of increased complexity. The potential complexity that arises from all the various attributes and their combinations can make it hard to know exactly what access is allowed or denied in some scenarios. Even though it’s easy to add new access patterns, if changes require modification of existing attributes, it can be difficult.
• Attributes are now critical for security. Since attributes are now used to control access, they must be managed carefully. Access to change attributes now has a security implication, so must be controlled just like any other security action. In the case of AWS, attributes are implemented via tags, and managing these is not always consistent across services and resources.

Being aware of the challenges associated with ABAC is the best way to mitigate them, so that you can get the best results of the approach.

When to use ABAC

The complexity of setting up ABAC usually means it’s not a great starting point for all but the largest organizations. It’s good for dynamic environments, because you don’t need to pre-define all types of access.

The ABAC approach is a contrasting approach to role-based access control (RBAC), which considers the role of the entity to allow or deny the request. These predefined roles usually correspond to the business function of the entity, rather than its attributes.

For most organizations it’s better to start with RBAC and reach for ABAC when roles no longer meet requirements, or as they grow. ABAC becomes a requirement in larger environments where the complexity and scale of requirements rule out RBAC.

It’s worth noting that RBAC and ABAC aren’t mutually exclusive. They can be combined if needed, which is useful during migration between approaches, but this also introduces more complexity than just using a single approach.

Conclusion

Attribute-Based Access Control (ABAC) offers powerful, flexible security for growing organizations, especially in cloud environments. While complex to implement, ABAC's ability to handle dynamic, fine-grained access decisions makes it a valuable tool for mature security teams. As organizations scale, they should consider progressively incorporating ABAC principles to ensure robust, adaptable access control in an evolving security landscape.

‍