When it comes to security, authorizations must follow a strict principle of data minimization. All access beyond the purpose of processing is a violation of the minimization principle.
Risks in the authorization system are usually defined and evaluated. The classic approach is ultimately a principle of prohibition, which is simply based on the following principle: a user should not be able to execute certain actions or certain combinations of actions.
The principle of minimization is, however, a principle of requirement. A user should only be allowed to perform actions that correspond to the purpose of processing.
To highlight this (in a simplified way) with quantity structures, consider that of the approximately 60,000 business transactions in SAP, several thousand transactions (approximately 2,500 in the SAP Access Control rules) are listed in the classical risk definition logic and are regarded as risky. However, in terms of the minimization principle of data protection, any transaction that is suitable for exposing personal data is a risk if this isn’t needed for the specific purpose. Realistically, this is 20 times the amount.
This, however, not only leads to considerable challenges in terms of the amount of risk definitions but also in terms of the number of hits (again simplified). After all, every one of the users in the system deals with personal data in one way or another, and this is precisely what the number of hits would cover. It’s therefore almost worthless to say that almost every user deals with personal data. The question is therefore, what do we have to prove? We have to prove which users have access for which processing purposes.
Activity Related Risks
From a user authorization perspective, activity-related risks can be divided into three different types of critical access into the system.
Segregation of Duties (SoD) Conflicts
SoD conflicts are the result of a combination of two activities. For example, the combination of supplier maintenance and order processing is critical. However, depending on rules, procedures, and Customizing settings, an SoD conflict can also be displayed within a transaction if the set of rules stipulates an SoD between entering and releasing a posting. The technical control of these various activities allows for an operation-oriented SoD; that is, a separation of the entry and release processes can be configured.
Critical Actions
Critical actions affect a single activity (execution) leading to a risk. Maintaining metadata preferences, for example, is a critical action because it can result in the production system being opened for unauthorized modifications. A critical action is defined as the connection of an application, for example, of a transaction with an authorization object.
Critical Authorizations
Critical authorizations are critical in themselves, without the type of access to this authorization needing to be defined already (technical definition: authorization object without connection to a specific transaction). One example is debugging in change mode.
This is what the “classic” risk perspective has to offer! What about the risks based purely on data protection law?
In data protection, the SoD is particularly important for system-related activities, such as the segregation of user administrator and authorization administrator, or the SoD in transportation management (transport requests between development and production systems.)
SoD requirements explicitly linked to business management should be borne in mind, for example, when customers or suppliers are unblocked. The allocation of a special bonus and the initiation of payment are still a risk of SoD in terms of business management; this risk doesn’t have to be subject to any data protection considerations. The risks involved in the SoD, therefore, play a rather marginal role in data protection in terms of volume.
Critical Actions and Authorizations
Critical actions also exist in data protection. Naturally, technical actions are more serious. The previously mentioned general maintenance of metadata preferences is also an explicit data protection risk. Specifically, with regard to data protection, it should also be noted that unlimited access to tables generally constitutes a massive violation of the minimization principle and the principle of purpose separation.
The definition of critical authorizations in data protection is much more important than in classic risk assessment. For example, access to internal vendors (e.g., travel expenses) is a risk for all users, regardless of the type of access, who aren’t explicitly authorized for the purposes relating to internal accounts payable.
The requirement to only provide authorizations if the access is covered from the purpose of the processing leads to a new category. The latter must be in a position to provide information as to whether the separation of purposes in the user’s authorizations has been carried out in such a way that the user only has authorizations resulting from the purposes for which he has to be authorized. The term purpose risk has been introduced to describe this risk.
Purpose Risk
A purpose risk is a general, purpose-oriented risk definition using the authorization objects assigned to individual artifacts within a purpose, as well as the LOAs and POAs of a purpose. The purpose risk is therefore made up of a set of all critical authorizations as defined by data protection law in relation to all artifacts of a processing purpose.
Let’s begin by taking a look at the graphic below. In this context, the sales order is protected by two essential authorization objects: V_VBAK_AAT (Sales Document: Authorization for Sales Document Types) and V_VBAK_VKO (Sales Document: Authorization for Sales Areas). The division, distribution channel, or sales organization may be used as LOAs. The POA is the order type. The activity is negligible for this assessment.
Given that sales organization n:1 is linked to the company code, a potential risk definition is as shown in this table.
This artifact-related observation must now be repeated for each artifact in the purpose until all risks have been defined.
The cumulative total of all risk definitions (which are in fact definitions of critical authorizations) represents the entire purpose risk. Thus, two levels can be represented: one general level that provides information about the purpose, and a concrete level that also identifies the artifacts in relation to the purpose.
If you’ve been following a procedure model where significant values have already been determined, they must also be applied accordingly. To do this, you’ll have to prepare the artifacts for their SAP ILM objects, for which you’ve already created rules. If you’ve already set up the Data Controller Rule Framework, you’ll find yourself in the comfortable position of having POAs, LOAs, and SAP ILM objects already assigned to the purpose.
Conclusion
Data is an important part of any business, but it’s important to keep data protected and safe from unauthorized access—both from outside and within the company. In this blog post, you learned about some types of authorization risk to consider when crafting a security strategy for your SAP system.
Editor’s note: This post has been adapted from a section of the book GDPR and SAP: Data Privacy with SAP Business Suite and SAP S/4HANA by Volker Lehnert, Iwona Luther, Björn Christoph, Carsten Pluder, and Nicole Fernandes.
Comments