Don't Be Taken Aback By ABAC

Introduction to IAM and ABAC

Identity and Access Management (IAM) is one of the most critical domains in information security. When prioritising security uplift initiatives, IAM is often the best starting point. IAM mechanisms facilitate the authentication and authorisation of users and machines, verifying the principal's identity and enforcing the associated authorisation level for the respective subject or system.

In our dynamic digital landscape, securing access to sensitive information and resources can present a significant challenge with the exponential growth and continuous change of technology. Traditional access control models rely on user roles or group memberships and struggle to keep pace with evolving security threats. Furthermore, identity administrators exert significant effort in constant identity management and provisioning of access rights. Granular, context-restricted, and least-privilege access control (often closely related to zero-trust) is an ideal that security and identity professionals see as a target state for their IAM environment. However, when applying these principles to outdated processes or access models, the challenges compound exponentially.

Identity and Access Management mechanisms require an underlying access control model that defines how permissions are controlled and applied to users and resources. The three most commonly used models are:

  • Role-Based Access Control (RBAC)
  • Mandatory Access Control (MAC)
  • Discretionary Access Control (DAC)

Attribute-Based Access Control (ABAC) is a less-used yet powerful model offering granular authorisation control through an adaptable approach. ABAC controls access to resources based on various attributes. Attributes can be associated with the user, the object(s) they are trying to access, or the environment. Attributes could include the user role(s), location, time of day, device type, and more. By leveraging dynamic attributes, ABAC allows for fine-grained control over access privileges, ensuring users can only access resources they need and precisely when they need them.

Dynamic Access Control and the Pathway to Zero Trust

The power of ABAC stems from its dynamic access control, where the control plane considers various factors in real-time to determine access decisions. Here is an example of a user attempting to access an HR document in a central file share where the document has the following attribute access policy:

  • The user accessing the document must be part of the HR department (user attribute).
  • The user must have accepted the latest Acceptable Use of Technology policy (user attribute).
  • The user can only access the file between 8 am and 6 pm (environment attribute).
  • The user must use a device that meets device compliance requirements (environment attribute).

The policy above provides a clear insight into the differentiation between a standard RBAC access model and ABAC. Where a traditional access control model (such as RBAC) would solely rely on a permission matrix to grant access, ABAC evaluates several other attributes associated with the user, resource or environment to determine the appropriate action. Such an authorisation pattern exemplifies dynamic access control, where the underlying IAM mechanism evaluates each request in context to a diverse set of changing attributes.

The nature of dynamic access control provides the capability for fine-grained policy implementation that enforces various conditions in line with business security requirements. In combination with other mechanisms (such as a device posture analysis agent), ABAC rules can evaluate the security health of a user device and enforce appropriate access restrictions.

As many organisations are adopting Bring Your Own Device (BYOD) policies, allowing users to operate their personal devices when accessing corporate systems, ABAC can selectively provide access based on device health or management status. If (as in the example above) the user device is not enterprise-managed or does not meet a predefined security posture threshold, ABAC can selectively restrict access to sensitive data. Where the posture threshold is low, ABAC can explicitly deny all access or permit access to selective (less sensitive) resources, such as the corporate event calendar and internal news blogs.

Inherently, the core philosophy of "never trust, always verify" is shared between ABAC and zero trust, providing a perfect opportunity for organisations looking to adopt the zero trust security model, where ABAC can be a great starting point. With the implementation of ABAC, organisations gain alignment with the following zero-trust security principles:

  • Granular Access Control: ABAC leverages a range of factors (attributes) for access decisions, going beyond permission matrix-based models (such as RBAC) and aligning with zero trust requirements for context-aware authorisation.
  • Dynamic Authorisation: ABAC makes access decisions based on various changing attributes, aligning with the zero-trust principle of continuous verification, which ensures access verification on each request. For example, an authorisation may fail if a user device moves from a compliant to a non-compliant state at any time throughout their session.

To successfully adopt ABAC as an effective authorisation model, organisations must invest significant time and effort into defining access policies and enforcing strict metadata hygiene processes. Once implemented, organisations can benefit from a granular security authorisation mechanism that provides comprehensive security benefits and reduced administrative overhead.

ABAC in the Cloud

Traditionally, managing access in AWS is applied via IAM policies that grant permissions based on user groups or roles using the native IAM service. In an improved pattern leveraging AWS IAM Identity Center and federated SCIM/SAML access, each group maps to a collection of permission sets and managed accounts, defining the access users inherit. While this approach simplifies initial user management, it can become cumbersome as the AWS environment grows, requiring more effort to manage granular permissions across numerous accounts.

AWS engineers (and FinOps personnel) should already be familiar with the concept of tagging, where you can attach metadata to cloud services such as EC2, ECS, Secrets Manager and S3 (to name a few). In addition, IAM principals can also have tags applied - principles can have tags applied directly (in the AWS native IAM service) or inherit attributes (as tags) from an identity provider (IdP) via the SAML protocol.

The AWS IAM ABAC capability provides the mechanism to granularly and dynamically control access to various services and resources. When creating IAM policies, you can specify, allow or deny requests by using a policy that compares the attached metadata of a principal and a target resource. When inheriting tags (attributes) from a central IdP, they are automatically propagated into AWS upon login, creating a dynamic access control environment. For example, if a user were to change departments within an organisation and an IAM policy evaluated access based on the department attribute, the user access scope would be automatically modified upon application of the change to the IdP at their next login (via the SAML assertion).

The example architecture below highlights how a central IdP can propagate identities, groups, and associated attributes into the AWS IAM Identity Center. Within the AWS IAM Identity Center, a mapping configuration between the groups, accounts and permission sets defines the level of access users within the group can assume. In addition, the permission sets define attribute-based policies that allow or deny access based on the attributes assigned to each respective user, including attributes such as department, branch, sensitivity level and more.

The example below uses a colour representation for different attribute combinations. The three colours (red, blue and black) define a unique combination of attributes into one visual representation. For example, red represents that the user is part of the FindOps - Tech department and is stationed within the East branch, while blue represents the DevOps department and stationing within the East branch. Some attributes can be consistent across all colours, such that the Acceptable Use of Technology policy signed attribute must be True.

While the definition and implementation of ABAC in AWS may require invasive change, such as strict tagging hygiene and changes to access definition patterns (such as IAM policy templates), the benefits on security and IAM operations can be significant.

  1. User accounts are provisioned directly within the organisation's identity provider (IdP) and applied to appropriate AWS group(s) in line with their business function.
  2. The AWS groups and the associate users are synchronised into the AWS IAM Identity Center via the System for Cross-domain Identity Management (SCIM) protocol.
  3. The user authenticates to IdP and is redirected to AWS via the Security Assertion Markup Language (SAML) federation between the IdP and AWS IAM Identity Center.
  4. Upon successful authentication, the user is presented with access options within the AWS IAM Identity Center dashboard, in line with group mapping into specific permissions sets and AWS accounts.
  5. The user attempts to access the AWS Systems Manager (SSM) service and is granted or denied access based on defined IAM policies.
  6. The user with the blue tag is granted interactive access to the blue tag EC2 instances based on ABAC control specifications defined in their associated IAM policy.
  7. The user with the blue tag is denied interactive access to the red tag EC2 instances based on ABAC control specifications defined in their associated IAM policy.

Conclusion

ABAC represents a paradigm shift from typical enterprise identity and access management practices. While the model may seem complex at first glance, its benefits can be significant, offering unprecedented granularity, flexibility, and scalability.

ABAC is a powerful access control model requiring significant development effort for policies and processes that will ensure adherence to strict metadata hygiene rules. As a result of the time and effort, adopting ABAC can strengthen security posture, mitigate authorisation risks (such as privilege creep), streamline provisioning workflows, and ensure compliance with regulatory requirements.

So, don't be taken aback by ABAC - embrace it as a secure, scalable and dynamic access control model.