Chapters
Share Article
Quite a few SAP customers are currently migrating their systems to the new S/4HANA platform. This represents a great opportunity to re-think SAP security for S/4HANA right from the outset. However, there are several challenges to securing S/4HANA. Despite sharing numerous settings with the “old” SAP Business Suite, some things are fundamentally different in S/4HANA.
The core system for SAP S/4HANA, like the SAP Business Suite, is still the SAP NetWeaver Application Server ABAP. Looking at it from a security perspective, there are more things that SAP ERP and S/4HANA have in common than what sets them apart. However, there are some key differences. As the HANA technology evolves, it will mean that eventually, S/4HANA will not only be an ERP running on a HANA database, but the underlying application server will also change, leading to more and more applications running natively in HANA.
These native SAP HANA applications are no longer relying on the ABAP stack and therefore are not hardened via traditional security controls for ABAP. Additionally, SAP S/4HANA offers a high degree of simplification through SAP Fiori apps that replace the old SAP Business Suite transactions. These Fiori Apps are based on standard internet technologies, which make it easier for SAP to share them with external users. However, this “opening” of access to ERP functionalities involves interactions with the underlying network security infrastructure that need to be considered.
SecurityBridge is a modern SAP security suite, natively build in SAP. It uses an ABAP based intrusion detection system (IDS) to guard your SAP landscape 24/7. Its frontend is fully Fiori enabled, which provides you an instant overview on the security posture of your ABAP, Java and HANA based systems.
Furthermore, some companies have moved their processes to the cloud. SAP S/4HANA enables a much better integration into these cloud-based services in a hybrid scenario. The security department needs to closely monitor the security-posture of this integration with SAP (and other) cloud services. Finally, access to different applications and instances must be coordinated, which requires smooth, efficient and centralized user and authentication management.
Specifically, the following areas must be closely watched in order to secure S/4HANA systems:
Redesign of roles and permissions
A conversion to SAP S/4HANA is essentially an upgrade. This also means that a redesign of roles and authorizations is necessary. For example, S/4HANA includes some new checks for authorization objects as well as new transactions. Experienced knowledge of the security transactions SU24 (Maintain Check Indicators) and SU25 (Upgrade Tool for Profile Generator) makes the tasks required much easier to implement.
The security baseline delivered in the SecurityBridge standard ensures you do not require an extensive side project while implementing S/4. Upon installation of SecurityBridge, all security-critical roles and authorizations are instantly monitored.
SAP S/4HANA also contains new SAP Fiori apps. The authorization users need to access these applications is not difficult to configure, however, it also represents a major design change in how roles are created. If you are using the role creation transaction (PFCG), it’s obvious that it now contains new mechanisms for integrating applications and for communicating and synchronizing with the SAP Gateway.
Securing the SAP HANA System
Some of the security settings and authorizations for HANA are obviously different, even at the basis level. For example, with SAP HANA 1.0, certain developers and administrators needed to access the SQL port of the database, and as the SAP HANA Studio was connected to this port, it posed a potential security weakness. With more current HANA versions, the administration is mainly done using a web interface, with the added benefit that access to the Web service ports of the application server alone, is sufficient. If not, access to the SQL port should only be allowed from dedicated workstations using, for example, IP or MAC filtering.
Another area that is relevant for security is the new authorization design of the extended application services of SAP HANA XS Advanced Model (XSA, the development, and runtime environment for native SAP HANA-based applications). This model for creating roles and authorizations, introduced with SAP HANA 2.0, differs significantly from the traditional database and security management of the SAP application server. Granting access to administrative applications is another task that must be considered when securing a S/4HANA system.
Ensuring a strong security infrastructure
With S/4 HANA, companies are opening-up business processes to the outside world, e.g. offering individual services to suppliers and customers. This also means that these processes are executed in real-time. Historically, in the closed SAP world with SAP GUI, it could be difficult to allow external users to access certain parts of the business applications, but with SAP S/4HANA and its’ SAP Fiori technology, it becomes easy to publish dedicated applications to other users outside of the corporate boundaries. However, granting access to business-critical system components must be thoroughly secured, and therefore a strong security architecture is essential.
Securing your SAP landscape is no longer optional. Security shall be unavoidable but workable, a core requirement within today’s interconnected world. For this reason, SecurityBridge is designed to be always on, 24/7.
Cloud Application Integration
Instead of allowing certain external user groups to access local applications, its often easier and more secure to let users interact with cloud services. Many companies have at least partially moved their processes to the cloud, and SAP S/4HANA provides an easier way to exchange data in real-time with environments such as the SAP Cloud Platform. This is usually achieved using the Cloud Connector, which connects SAP Cloud Platform applications easily and securely to on-premise systems such as SAP S/4HANA.
To support hybrid business processes that include both SAP S/4HANA on-premise and cloud applications, the Cloud Connector should be configured and operated in a secure manner. In addition, the SAP Cloud Platform Identity Authentication and SAP Cloud Platform Identity Provisioning services should be used when creating authorizations for cloud applications.
User access and authentication management
One of the biggest challenges with digital business scenarios is coordinating the different types of access, especially in hybrid landscapes. Users may need to be set up not only in the SAP S/4HANA core system but also potentially as native users in the SAP HANA database itself. These users must have access to the SAP Gateway, which provides the application catalog for the users, and to all connected cloud applications. Additionally, users should also use single Sign-On methods of authentication.
Since SecurityBridge also monitors your HANA database and its security audit log, it correlates events and identified vulnerabilities across different SAP technology layers.
These examples mentioned above only represent the very most important topics to consider when securing S/4HANA and HANA in general. It becomes apparent, that these topics are fundamentally different from the way “traditional” SAP systems, based on ABAP only, need to be secured. While this represents a huge opportunity to consider security from the outset of any HANA migration project, there is another angle to this: hackers will most likely try to exploit the relatively low knowledge regarding securing HANA and run attacks targeted specifically at the new SAP flagship.
We therefore strongly recommend you start by securing HANA from the initial implementation and ongoing, monitoring with full diligence as you would for any other business-critical system.