Sap Field-level Security: Complementing Roles With Attributes

By Author: appsian
Total Articles: 115
Comment this article

Attribute-Based Access Controls

With attribute-based access controls (ABAC), an organization may integrate additional contexts such as geo-location, time of day, and IP address, etc. The SAP ABAC is an example of that. This ensures that only authorized users access the services, and prevents users from getting more access than they need at the same time.
Such granular, data-centered access privileges allow an organization to ensure that users – internal or malicious – do not have access to sensitive ERP data, thus mitigating the potential negative effects of an intrusion into the corporate network by hackers.

RBAC+ABAC Hybrid Approach to Data Security

Let us now explore how a combination of RBAC and ABAC approaches can enforce field-level security.

Consider a multi-national company with offices in many countries. Now, let's say that the organization has a policy that allows any 'HR Manager' worldwide to access employees' basic information. Still, some unique data (compensation of US-based workers, for example) of an employee can only be accessed by an 'HR Manager' who is a US citizen and ...
... works in a US area. Many of the fields in this example would need to be shielded from users who do not meet the criteria for citizenship and location.

Notice that in this case, the citizenship of the user and his position must also be considered in addition to the function of the user (HR Manager), before any employee data can be displayed.
What does a company do to fix this problem in the conventional implementation under RBAC?

An organization usually adopting the old RBAC model will create roles for the 'HR Manager' for various countries, and then another set of roles for the user's citizenship. Note that the user's 'location' attribute at the time of access cannot be supported.

Despite the lack of 'location' support, a role-based approach cannot be scaled-up and becomes cumbersome to maintain in a sizeable user-population enterprise. Besides, if the policy changes allowing permitted exceptions, the changes must be made to all items created to address the policy.

Now let's consider adopting an approach that includes both RBAC and ABAC (for instance, SAP ABAC) to simplify implementation.

We will create one role for the 'HR Manager' in this hybrid approach. This would be common across the company to all HR Managers worldwide. Other attributes like Company Codes, Offices, and Citizenship are the user's individual attributes. And location can be considered as a dynamic attribute.

In attribute-based access control, these user's attributes can be made available for evaluating access controls and ensure field-level security.

Ideally, the Views/Fields behavior should be evaluated based on the users' runtime attributes attempting to access the transactions.

When we consider designing a field-level security solution for controlling data access, there are three high levels of attributes that would determine the screen objects' behavior:
1) Identity- e.g., Roles, Citizenship, Level of Skill
2) Context- e.g., Location, Device Type
3) Content- e.g., Employee Details
The paradigm shift in this model is that the behavior of the business object Fields/Views is not governed by roles alone, but by three sets of attributes, providing us with a much more nuanced and more granular control of business object data. This is a more scalable approach and can support dynamic changes.

Despite all of the above features, there is still potential for a data breach, as evidenced by the recent spike in phishing attacks across organizations. Therefore, investing in additional data security platforms to provide robust data protection is essential for companies.

Appsian One of the leading ERP data security,compliance,implementation solutions provider that gives organizations to complete control and visibility over their ERP data.