How To Strengthen The Security Of Your SAP S/4Hana Application

[Former Member]

In migrating from SAP to SAP S/4HANA, a lot of the usual security procedures have been changed significantly. This is partially due to the fact that SAP S/4HANA is a different type of database system and it interacts with both users and administration differently, thanks to its use of the cloud as a basis for running its services and custom applications. Securing applications that communicate with your SAP S/4HANA install is an essential part of overall security. That said, what steps can you take in order to ensure that your SAP S/4HANA installation is secure?

Dealing with the Basics

At the start of securing an S/4HANA install, there are a handful of things that need to be addressed before we can even consider moving further. These are:

1) Authorization procedure and user roles: The basic functions of a SAP database require the standard security transactions be done in order to allow for free and easy movement of data across the network. For the network admin, this means a good familiarity with SU25 (Upgrade Tool for Profile Generator) and SU24 (Maintain Check Indicators). Additionally, with the use of SAP Fiori apps, how you think of roles must change since SAP Fiori apps utilize different types of transactions in order to sync and update their internal data with the database. This requires you to dig deeper in the PFCG and understand its functionality to properly deal with the establishment of roles in keeping with what you want your users to accomplish with your SAP S/4HANA install.

2) Security of the overall S/4HANA System: In order to limit security breaches, it is recommended that you only allow access to the SQL port from authorized systems (e.g. Windows Terminal Server [WTS] connected stations). Additionally, for custom applications that require security protocols in order to access the database, network administrators need to familiarize themselves with the required security access levels and how to implement them alongside the custom application coding. If custom development isn't on the cards for your organization, then understanding the security protocols to this depth may be safely overlooked.

3) Developing a Strong Security Architecture: Thanks to SAP Fiori, the ability to publish dedicated applications to small portions of clientele allows for added functionality of the system. However, it creates a lot more problems in terms of security since it potentially allows intrusion if the security systems within these applications are not managed properly. Transport Layer Security (TLS) protocol alongside firewalls and a healthy application of the Remote Function Calls (RFC's) to the SAPRouter in order to reverse invoke connections can create a very solid wall for those who intend to utilize these applications in order to breach the system.

4) Individual User Access: Security in a hybrid system is a complicated thing, especially for SAP installs, since in addition to regular SAP access, SAP Fiori and custom application users also need access to the gateway that permits them to run applications, but separately from the standard SAP NetWeaver AS ABAP system. In order to simplify things for users, an understanding of Security Assertion Markup Language (SAML) 2.0 is a necessity. Cloud users can be stored and administered separately from S/4HANA users, simplifying the system. It must be noted, however, that this may create problems in reconciliation of accounts across S/4HANA users and their mobile accounts.

Core Security Concerns

While we have explored the basics of an S/4HANA install as well as taken a look into how the management of an app-based interface for a casino online would look like, we still need to concern ourselves with securing central system, the core of our SAP S/4HANA install. Among these are:

• User Protection Updates: Replace standard passwords for SAP*, DDIC, and TMSADM with new, stronger, secure versions, and updating affected users by running RSUSR003.


• Securing Custom ABAP Code: Each month SAP releases new security patches that need to be added to applications to ensure their continued security. This can be done automatically for affected code.


• Data Packet Transmission Security: Implementation of TLS and Secure Network Communication (SNC) protocols.


• Configuration Data for Server: Ensure all security settings are implemented and conform to the required settings.


• Enable Logging: This ensures that no attack data if it exists is lost.


• Protection of User Credentials: Cease using outdated hash storag methods and develop a secure method for maintaining hash tables.


• Secure the Interface: Restrict access by removing the SAP_ALL profile with regards to technical users. Use Unified Connectivity (UCON) as well as RFC's to reduce the effective area that an intruder can attack.

The Start of the Race

While the suggestions mentioned here provide a basis for setting up security for a S/4HANA install, it is by no means the final word on S/4sHANA security. On the contrary, like all security in general, there will always be an arms race to stay ahead of potential intruders. Security is always going to be a concern for enterprise-wide software and SAP databases are only as secure as their network personnel allow them to be. It's a constant tradeoff between accessibility and security, but by establishing a solid, documented foundation for your security implementation, you set up a definitive platform that can be used to deal with threats as they occur.

Constant observation of SAP's white papers on the subject of security is a necessity for this security strategy, but it is by far the most effective in securing a company's data against external attack. The added complication of the cloud does make the situation more complex, but it’s not something that can’t be dealt with by skilled network administrators with a proper grasp of the system itself.