As your company’s digital footprint grows, you can enhance your security posture by complementing your existing SAP Role-Based Access Controls (RBAC) with dynamic, Attribute-Based Access Controls (ABAC) to strengthen authentication and authorization. Both RBAC and ABAC are ways that organizations can control authentication and authorization, but they perform different functions across an enterprise IT stack.
Functionally, a role is a collection of permissions using sets, relations, and mapping that align access needs to resources based and limit access on a “need to know” basis.
RBAC involves three basic principles:
RBAC has since evolved to include “hierarchies.” Hierarchies assign different roles different levels of access. For example, a Chief Executive Officer (CEO) needs to have a lot of access to sensitive information. Therefore, the CEO role has access that also encompasses the type of access provided to the Vice President’s, line of business managers, and standard employees. However, since a standard employee is at the “bottom” of the hierarchy, RBAC prevents her from accessing the sensitive information that the CEO can access.
RBAC provides a strong foundation for setting access controls. However, digital transformation changes the way people interact with data resources. Since RBAC was intended for on-premises data repositories, it creates a very strict, static set of permissions. You either have access or you don’t.
Dynamic authorization – also known as attribute-based access controls (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 or resource.
Examples of user attributes:
Examples of action attributes:
Examples of resource attributes:
Example of environment attributes:
By incorporating these attributes, organizations can control user access more precisely, and with the flexibility of dynamic authorizations, better balance business and security requirements.
Roles act as the foundation for providing access. If you think about it like a sentence, RBAC is the subject and verb. An IT admin has what we call “superuser” access. 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 struggle to restrict IT administrator access while still providing enough access for the employee to do their job.
However, if we add attributes, or additional descriptors about how/when/where IT administrators can use their access, we limit the risk. By creating an “if-then” statement, we apply restrictions based on 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 defense 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.
Without a solution like Pathlock, the closest and organization 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.
Contact us to learn how Pathlock can help you extend and enhance your existing SAP access controls and improve your reporting and auditing capabilities.
Share