ABAC enhances RBAC by taking into account different “attributes.” Attributes are the ‘adjectives’ of the access control world because they incorporate an additional description of either the user, resource, the action they are trying to perform, or the environment in which they are in. Common examples are;
By incorporating these attributes, organizations can control user access more precisely, and with the flexibility of dynamic authorizations, better balance business and security requirements.
Existing SAP Roles act as the foundation for providing access, what we call Role Based Access Controls, or RBAC. If you think about it like a sentence, RBAC is the subject and verb. If say, an IT admin has what we call “superuser” access then a simple RBAC sentence might look like this:
"IT administrators can read and edit all information."
Based on RBAC, this sentence provides so much access that an IT administrator could be a data breach risk. Whether maliciously stealing sensitive information or accidentally sharing private information, the unrestricted access means organizations would struggle to restrict IT administrator access while still providing enough access for the employee to do their job.
However, by adding ABAC rules on top of this, we can add attributes, or additional descriptors about how/when/where/what IT administrators can use their access, and significantly limit the risk. In effect, we are creating an “if-then” statement to apply restrictions based upon the defined characteristics:
"If IT administrators are accessing the database (resource attribute) from their homes (environment attribute) then they can read (action attribute) the information."
By adding these attributes, we can prevent IT administrators from making changes to databases while they are at home. Furthermore, we can use attributes to grant access as well. Taking the same statement, let’s incorporate time of day as an additional attribute.
"If IT administrators are accessing the database (resource attribute) from their homes (environment attribute) then they can read (action attribute) the information, but if they access the database between 8 AM and 10 AM (environment attribute 2), they can edit user data (action attribute 2). "
By adding the additional environment and action attributes, you’re creating a scenario that allows IT administrators to work from home while also reducing the risk. You have created a time-bound restriction that requires them to only make user data changes during the hours of 8 AM and 10 AM if they are at home while at all other times, they can only read the database information.
The more attributes you can incorporate, the more precisely you can define what, how, and when a user or group of users can access data.
As organizations accelerate their digital transformation initiatives and allow more remote access to data and transactions, they need a way to configure a layered defence using a hybrid approach to SAP access control.
Starting with RBAC, organizations set the foundation of their access policies. However, by incorporating different attributes such as user, resource, action, and environment characteristics, you can more appropriately limit access to and within your SAP data.
Using the standard SAP roles, the closest an organisation can come to granting dynamic access to SAP is through customization or adding roles to a user for each attribute. Both options are costly and ultimately unmanageable in the long run.
However, with our Appsian products (https://www.greymonarch.com/SAPSEC_Appsian_Overview.html) , you can add and enforce Dynamic Authorisation controls easily and quickly within any SAP environment, allowing you to also mask sensitive data - something we will explore further in our next article.
Grey Monarch have specialised in SAP security since 2008 and, along with our key partners, Appsian and Protect4S, we can offer SAP customers software, automation, and consultancy to delivery highly secure SAP environments.