Attribute Based Access Control (ABAC) Policy Examples
If you are a business owner, IT manager, or IT admin, access control for your company documents and data is always top of mind. Cyberattacks do not just come from outside your business, internal problems cause devastating security breaches. An Interpol report found that the costs associated with insider threat breaches reached an average of $7.68 million in 2020.
Business owners all over have questions such as:
- “How to keep company resources safe from threats?”
- “Which access control system is capable of addressing every access scenario?”
- “Which system works better for diverse/time-defined workgroups?”
- “Which system works for creative enterprises?”
- “How to securely leverage data across an organization, business partners, and third-party suppliers”
This is where Attribute-Based Access Control (ABAC) comes in.
Defining Attribute-Based Access Control
Having evolved from Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC) is an authorization best practice that uses attributes rather than roles to grant access. You can use ABAC systems to set control based on user attributes, resource attributes, and environmental attributes. It is used to grant access to those connection requests that satisfy the attribute values defined by the organization’s security policy.
How do ABAC and RBAC work?
Every user is assigned a set of user attributes upon employment (e.g., Vasudev is an Engineer in the Highways Department.). A resource is assigned its attributes upon creation (e.g., a folder with Records of Flyovers). The administrator or the object owner creates an access control rule to govern the set of allowable operations (e.g., Engineers in the Highways Department can Edit the Flyover Records).
Attribute Pool
- Subject attributes – Aspects that describe the user
e.g. Id, age, job role, clearance, department. - Object attributes – Aspects of the object being accessed
e.g. bank account, medical record, file. - Action attributes – Aspects of the action being initiated
e.g. read, copy, delete, view, approve. - Environment attributes – Aspects that deal with the dynamics of every access scenario
e.g. subject’s behavior pattern, time, location.
ABAC is responsible for extracting the attribute values from connection requests and looking for matches with the planned policy. An access request is granted as long as the planned policy is satisfied.
Whereas RBAC controls access based on the user’s role. Every user is assigned to a role, which in turn carries privileges and permissions. Those permissions allow the user to work on the resources they are trying to access.
How ABAC differs from RBAC
For example, consider the following policy:
“If the subject is in a writing job role, they should have read and edit access to the marketing team assets.”
An interpretation of this policy from an attribute-based perspective would be:
Subject’s “job role” = “writing”
Subject’s “team” = “marketing”
Action = “edit”
Object “type” = “marketing team assets”
Object “team” = “marketing”
Fig 1. ABAC Policy Making
An interpretation of this policy from a role-based perspective would be:
User’s “role” = “writing”
Resource = “marketing team assets”
Permission = read, edit
Fig 2. RBAC Policy Making
Why ABAC?
Dynamic Context-Aware Decision Making
Authentication based on attributes allows dynamic policy-making. An example scenario to illustrate its use: if a user named “Radhe” is promoted from writing to management, her access permissions should be updated because her user attributes changed, not because someone remembered that she had admin permissions and took the time to update a configuration file somewhere.
So, without the need for admins to monitor each and every subject/object relationship, just attributes and their values may be modified throughout the lifecycle of subjects, objects, and attributes. This provides a more dynamic access control capability as access decisions can change between requests when attribute values change.
This is an unfortunately frequent situation frequently described to us by customers. It’s all too common for users to slip through the cracks, either due to poor communication between departments or a lack of established protocol for handling such transitions.
Subject-Object Relationship
Although RBAC makes managing access control simpler and faster, there are some things RBAC cannot do, primarily relationships. To establish granular policies, RBAC requires more and more roles, leading to role explosion.
The subject-Object relationship lets ABAC handle granular access control policy. Administrators have the luxury of choosing from a large set of attributes, which helps them formulate highly specific rules. You could give the same person different permissions based on where the person logs in or what the person tries to do on a different day of the week. (e.g. allowing only users who are type=employees and have department=HR to access the HR/Payroll system and only during business hours within the same time zone as the company), then you need ABAC.
An Extra Layer Of Security
Granting access based on attributes rather than roles ensures an extra layer of security that RBAC can’t provide. For example, with RBAC, a coder will likely have access to the whole development environment, regardless of their task. With ABAC, their access could be restricted based on attributes, i.e., location, time of day, and actions (viewing, editing, deleting data). If the coder attempts to access a new country beyond business hours, the authentication request should be denied as abnormal behavior.
This way, by using behavioral and contextual data analytics, ABAC can be used for access decisions and enforcement that is based on a dynamic risk assessment or confidence level of an act. ABAC allows organizations to grind on many different attributes as indicators of access, increasing the level of security.
Trouble-Free Onboarding
ABAC enables administrators and object owners to create policies that allow them to adapt existing rules for new users to access resources without having to add more and more policies. All administrators need to do is assign relevant attributes to the new joiners. There is no need to modify existing object attributes or rules. As a result, companies can flexibly onboard new staff and enable external partners.
Real-Time Evaluation
With RBAC, users arrive at the protected resource with their pre-assigned role, while with ABAC, user resource access is decided just in time. ABAC’s attribute richness allows just in time possible, based on when and from where access is being requested, such as time of day, location, from what device whether business hour and the same time zone as the company, the access can be granted just as much the situation demands.
For example, it could prevent access to a sensitive resource for an employee who is authorized to access it but is away on vacation and using unsecured public Wi-Fi at a coffee shop. It is this real-time evaluation that makes externalization of policy possible and enables dynamic access.
Deliver Better Customer Experience
Protecting access to customer data is critical, and it’s driven by three main factors: data privacy regulations, enterprise security needs, and customer experience expectations. Ensuring a good customer experience, as well as security and regulatory compliance, can be difficult given the amount of data involved, along with the number of people and processes required to make necessary changes and updates.
ABAC enables organizations to protect customer data from being accessed through unapproved sources. Enterprises can grant access to resources using customized permissions based on risk factors.
Cloud RADIUS with ABAC Support
There are various techniques for identity management to keep sensitive assets secured. ABAC manages user access based on contextual awareness than simple user-centric parameters such as their assigned role. RBAC would only consider if an employee has the privilege within a given system to access a resource. Active Directory (including Azure Active Directory) maintains a similar stance as traditional RBAC, where group enrollment determines permission. What’s more, groups can be nested within groups, which, without management, can violate Zero Trust guidelines and it demands administrative overhead.
If your organization lives in a SaaS-based environment, you would understand the nested group caveat (an employee or group that incorrectly becomes a member in one place could obtain potentially unauthorized access elsewhere and admins end up monitoring user over positioning). Today’s threat environment needs ABAC which provides real-time evaluation of connection requests. It is certainly, a better match than legacy directory access controls.
Organizations that use SecureW2 Cloud RADIUS have the strength of ABAC for user lookup, enabling attribute-based access control by referencing your cloud directory at the moment of authentication. Furthermore, our Cloud RADIUS can be configured to make policy enforcement decisions based on a wide array of custom attributes.
Check out our pricing page to see if SecureW2’s Cloud RADIUS servers fit your organization’s network needs.
