Migration to S/4HANA - Security and Authorization Challenges

It is estimated that by 2020, about 30% companies globally will start using S4/HANA in production (in 2018, only 2% of all companies were using S4). I will discuss two areas that should be addressed if we are to raise (or maintain a high) security level of the target system - authorization and technical level.

Authorization layer

Due to the fact that S/4HANA is a new solution from the SAP family (and not just the evolution of SAP ERP) - the transfer of authorization to a new environment cannot be realized without appropriate adaptation (e.g., some authorization is not in S/4).

What actions should be taken to convert authorizations?

At the outset, a decision must be made - whether for the target environment it is enough to transfer (with appropriate adaptation) the current roles (brown field approach) or to start working on a new set of roles (green field approach). Both approaches have their advantages and disadvantages. It all depends, first of all, on the state of the current level of use of assigned authorizations. We know from experience that The average value of the use of vested rights for an average organization (which has had SAP for at least several years) are values between 10-15%. And this may mean that the assigned role permissions are not optimal - so the choice of approach should be scaled (often with such usage statistics, greenfield is the best approach).

For the approach brownfield we use SAST tools, which support the conversion of authorization to S/4HANA (some manual work is required). For testing new roles - we are implementing a tool to facilitate production deployment of roles (more on that in a moment).

On 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.

It is also necessary to verify critical accesses in roles and conflicts of authority, and update SU24. In general - without revamping the authorization concept, migration is impossible.

Secure launch of roles on a production system - testing

Any project work that involves test users is at risk of oversight. Creating new roles and testing them before production deployment is critical to business process execution. If new roles are not sufficiently tested - there is a risk of not being able to perform their tasks. That's why we have introduced support for this stage, automating the testing process (granting, creating testusers) and implementing the ability to fallback to old authorizations (fallback user).

In practice, it looks like this:

1 - the created (and pre-tested) roles are pinned to users (replacing the old roles),

2 - in the event that the user cannot perform some action (unable to work) - reverts to the old set of roles on an emergency basis (this happens automatically, the action takes 1-2 minutes),

3 - the administrator gets information about the user's activities, which differ from the new set of roles - on this basis, a decision is made on whether to complete new roles for the user.

Using fallback - activities on the production system have no downtime, even in case of errors in authorization creation/testing.

Technical layer

New installations S4 have a number of risks already in the default configuration itself (out of the box the customer therefore gets a set of parameters that he should adjust to increase the level of security). Risks in the target infrastructure S/4HANA generally fall into two areas: unsafe system configuration and client vulnerabilities ABAP.

We do a fair amount of security audits, and we also perform penetration testing. Experience gained during such projects confirms that the main reasons generating SAP security problems are:

- No implemented security guidelines (or no patches),

- No separation in the network,

- lack of monitoring tools.

Process model for secure migration is SAP HANA

Verification of security level

1 - verify the security level of the target system (good practices of the SAP security market, identifying the most pressing problems, will be useful),

2 - Arrange the risks found into a report with information on corrective actions,

3 - create priorities for risks to improve security.

Increase the level of 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 are devoid of authorization objects) are also important.

It is important that those responsible for the area are involved in the work to confirm that the changes have not affected existing processes. One challenge is undoubtedly client ABAP programs. Organizations rarely have detailed descriptions of all programs and equally rarely have knowledge of those programs that are particularly used. This manifests itself in the fact that in the thicket of several thousand Zetas, only a few dozen/some hundred are the ones used in daily work. It is therefore necessary to collect relevant information regarding the use of programs. We identify the programs that are not used and minimize the risk with the "Soft Cleaning" methodology. With this approach, we are able to reduce migration costs, and the code cleaning component itself is 80% faster (and cheaper) than the standard approach.

Security monitoring

After sealing the environment - start monitoring it. Any critical change in settings should be caught right away. And here, too, this applies to those layers that are important from the SAP point of view.

Summary

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 detected, the lower the costs associated with resolving them. It is up to the organization to decide on the necessary steps and risk mitigation. We, at S/4HANA, are able to help at every stage of securing your SAP system.