It is estimated that by 2020, around 30% of companies globally will start using S4/HANA in production (in 2018, only 2% of all companies used S4). We will discuss two areas that should be addressed if we want to raise (or maintain a high) level of security of the target system—authorizations and the technical level.
Because of the fact that S/4HANA is a new solution from the SAP family(not only an evolution of SAP ERP)—the transfer of authorizations to a new environment cannot be carried out without appropriate adaptation (e.g. some authorizations are not in S/4).
What actions should be taken to convert authorizations?
At the beginning, it is necessary to decide whether it is enough to transfer (with appropriate adaptation) the existing roles for the target environment (brown field approach) or start working on a new set of roles (green field approach). Both approaches have their advantages and disadvantages. Everything depends primarily on the state of the current level of use of the authorizations granted. We know from experience that the average value of the use of the granted rights for an average organization (which has had SAP for at least a few years) are values between 10-15%. And this may mean that the permissions granted in the roles are not optimal - therefore, the choice of approach should be calculated (often with such usage statistics, greenfield is the best approach).
For the approach brownfield we use the SAST tool, that support the conversion of authorizations to S/4HANA (some manual work is required). For testing new roles - we are implementing a tool that facilitates the production implementation of roles (more on that in a moment).
At the approach greenfield we work on the methodology of creating risks and roles (based on conflict-free role templates dedicated to S/4HANA). Here we also support production testing of roles.
We should also verify critical access in roles and permission conflicts and update SU24. Generally, without reorganizing the authorization concept, migration is impossible.
Safe launch of roles on the production system - testing.
Any design work involving test users is at risk of oversight. Creating new roles and testing them before the production implementation is crucial from the point of view of the implementation of business processes. If the new roles are not tested enough, there is a risk of not being able to perform their tasks. That is why we have introduced support for this stage by automating the test process (assignment, creating testusers) and implementing the possibility of emergency return to old authorizations (fallback user).
1 – created (and pre-tested) roles are pinned to users (replacing old roles),
2 – when the user is unable to perform a certain action (inability to work) – he returns to the old set of roles in an emergency (this happens automatically, the action lasts 1-2 minutes),
3 - the administrator receives information about the user's actions that differ from the new set of roles - on this basis, a decision is made on whether to supplement new roles for the user.
Using the fallback function – activities on the production system have no downtime, even in the case of errors in authorization creation/testing.
New installations S4 have a number of risks already in the default configuration (out of the box, therefore, the customer receives a set of parameters that he should adjust to increase the level of security). Risks in the target infrastructure S/4HANA generally include two areas: unsafe system configuration and vulnerabilities in client solutions ABAP.
We carry out a large number of security audits, we also carry out penetration tests. The experience gained during such projects confirms that the main reasons generating problems related to SAP security are:
- no implemented security guidelines (or no patches),
- no separation in the network,
- no monitoring tools.
The process model for secure migration is SAP HANA
Security level verification
1 – verify the security level of the target system (good practices of the SAP security market will come in handy, identifying the most pressing problems),
2 - put the risks into a report along with information about corrective actions,
3 - prioritize risks to increase security.
Based on the report, risks and priorities, start sealing the environment. Remember that the layers below the SAP application layer (OS/net/DB) and client ABAP extensions (which may contain critical functions, calls or lack authorization objects) are also important.
It is important that people responsible for the area are involved in the work to confirm that the changes have not affected the existing processes. One of the challenges is undoubtedly ABAP client programs. Organizations rarely have detailed descriptions of all programs, and they also rarely have knowledge of those programs that are specifically used. This manifests itself in the fact that in the thicket of several thousand Zeteks, only a few dozen / several hundred are those used in everyday work. Therefore, appropriate information on the use of programs should be collected. We identify programs that are not used and minimize the risk with the "Soft Cleaning" methodology. Thanks to this approach, we are able to reduce migration costs, and the code cleaning element itself is 80% faster (and cheaper) than the standard approach.
Once you've sealed your environment, start monitoring it. Any critical settings change should be caught right away. And here, it also applies to those layers that are important from the SAP point of view.
Regardless of the size of the environment and its scope - as part of the migration to S/4HANA, we suggest looking at the security level of the target platform. At the end of the day, the earlier security issues are discovered, the lower the cost of resolving them. It is up to the organization to decide on the necessary steps and mitigation of risk. We are able to help at every stage of securing the SAP system.
author: /Tomasz Jurgielewicz/