By Soujanya Madhurapantula.
In SAP’s role-based security architecture, Users and Authorization objects are used to create profiles, such as “buyer” or “payer”, and these are used to define functional roles.
As a counter measure for potential fraud, the GRC Access Control Segregation of Duties can dictate that a user should not have, for example, both a buyer profile and a payer profile simultaneously. In simple cases like this, SAP’s authorization concept works great! It’s able to distinguish which user can perform a specific function by limiting their access to certain transactions, programs and services. It even provides an easy way to administrate HR functions like role changes and employee turnover.
Where RBAC Falls Short
Unfortunately, the Role Based Access Control (RBAC) authorization concept, which has been the defacto approach to system security since the mid-1990’s, is no longer a sufficient design given the context of today’s business.
When we take a common use-case of a contemporary UK multi-national chemical manufacturer, what happens when they want to initiate a joint venture with a foreign company to service an emerging market there? We would need to extend our access criteria to include several additional layers of data security. Why? Because we would need to serve location-based access restrictions that protect valuable recipes and technical data not related to the joint venture.
Assuming there are 10 distinct buyer profiles in SAP:
- Each would need to be replicated for each joint venture, plus presumably a “buyer_all” profile.
- When we extend the example to include compliance requirements from the Chemical Weapons Convention for chemicals produced by the US subsidiary, each of the profiles created would need to be replicated again to account for these additional restrictions.
- Further, additional custom authorization object development is often needed to integrate the SAP authorisation engine within the HR related data sourced from SAP HR (or external HRIS systems) to support data requirements that may be linked to an employee or contractor.
- Compound this with multiple SAP that a company will run throughout their supply-chain network.
The result is a “role explosion” within SAP’s management of the factors that contribute to “ACCESS” or “DENY” system decisions. In other words, the implementation of static authorization object based requirements results in an exponential increase in access rules compared to access variables. This approach often results in implementing more roles than actual employees, causing a severe administrative bottleneck because authorization assignment is a manual cost-incurring task liable to human error.
Not only do the roles explode, the resulting effect is severe authorization duplication. Doing some back-of-the-envelope math, we can see that if we take:
50 functional roles, with a single company-code authorization object carrying 5 company codes, we will end up with
- 300 total roles, of which
- 50 are parent roles, and
- 250 are child derived duplicates
When we expand the example to 50 functional roles with 40 authorization objects carrying 5 possible values each:
- 12,000 total roles, of which
- 2000 are parent roles, and
- 10,000 are child derived duplicates
While it is agreed that SAP GRC AC reduces these derived role explosions to an extent, but it still uses static authorization objects to define them, this is still only a retroactive countermeasure.
Static Authorization Concepts are an issue today and here’s why
This above is not an isolated example; data security has become one of the most significant challenges in global business due to two emerging pressures, globalisation and compliance. Growing business often necessitates increasing collaboration (internal/external and domestic/abroad), in areas such as engineering, supply chain, partnerships, and joint ventures. At the same time, organisations are increasingly dealing with regulatory compliance decrees such as CWC, ITAR, EAR, FDA 21 CFR Part 11, DOE 810, NERC CIP, SEC, German BAFA, UK ECA, among others.
This momentum is driven by a variety of pain points and they all increase the risk of critical SAP data being accessed by unauthorized users leading to loss of intellectual property and noncompliance:
- product development in trade restricted locations where legal protections are inadequate
- data leakage beyond project teams due to mishandling
- insecure or unmonitored data transfer or distribution between supply chain partners
- data lost on unprotected laptops, removable drives, or mobile devices
Attempting to meet these challenges, the according role-explosion due to ever-changing regulations, combined with the high risk exposure can cause the authorization process to deteriorate into gate-keeping.
Managing changing authorization requirements through static processes like RBAC is, at best, a retroactive fix, because while solving today’s access control, it also increases complexity and decreases transparency as time continues. Taken too far, risk exposure increases over time and can bringing about adverse financial ramifications.
Wouldn’t you agree?
Soujanya is the Product Manager for the Entitlement Manager for Enterprise Applications at NextLabs. She works with the Solutions Management team to devise best practices for securing and controlling data in order to develop solutions for Global 5000 business around partner collaboration, export regulations, IP and Data security.