Key security considerations for SAP S/4 HANA projects

Posted by Simon Persin on 21 June 2018
Simon Persin

This article appeared in E-3 Magazine International on 19th June 2018.

e-3 magazine

E-3 Magazine International, independent SAP trends, analyses, strategies and in-depth reports from business and IT.

Photo by Denys Nevozhai on Unsplash
S/4 HANA places an emphasis on simplicity. The data model has been made easier, the technical architecture is more straight-forward and business processes have been consolidated to support this reduced complexity. Whilst this simplification promotes increased performance and greater business value, it also dictates that migrating your existing SAP estate to S/4 HANA is not just an upgrade.

 

Many of the changes brought about by S/4 HANA have an impact on the security and role design for end users. S/4HANA uses Fiori as its primary user interface (UI) and this means that any role design needs to include Fiori Groups and Catalogs to determine what a user is able to view and access in the front-end.

 

The use of Fiori also places a much greater emphasis on the S_SERVICE authorisation, which is used extensively to secure the oData communications between front and back-end servers. There is also a significant number of transactions that have been made obsolete in S/4HANA because of the simplification and consolidation. The most obvious change is the replacement of the old vendor/customer master data transactions, which are replaced by the Business Partners (BP) application.

 

The BP app serves as a central hub for maintaining master data for business partners and vastly reduces the number of tcodes involved - although thankfully, access is still secured using familiar authorisation objects. The SAP documents related to the list of simplifications alone are 900+ pages and require due care and attention. All of these changes will also need to be reflected in a new S/4 HANA SoD matrix, be it an SAP GRC ruleset or otherwise, to ensure that access risks are reported accurately.

 

S_SERVICE authorisations wil also need to be incorporated into the SoD matrix to ensure that any apps that do not utilise S_TCODE checks are still monitored.

 

Key design decisions

One of the key design decisions when choosing to migrate to S/4 HANA, is whether to keep the existing role design and incorporate the necessary Fiori content or start again - thereby creating a new set of roles. Whichever path is chosen, there will be a unique set of advantages and disadvantages to be considered.

 

Keeping the existing role design may be advantageous if a lot of effort has been invested in ensuring roles are audit compliant and risk free. However, this will require obsolete transactions to be identified and replaced and extensive analysis to be performed to map in the service authorisations required to use Fiori.

 

Start from scratch means Fiori Catalogs can be used to pull through the authorisations required for each app to work. This will save effort, but will require familiarity with the Fiori launchpad designer to customise Catalogs - and the new roles will need to be reassessed to ensure that they are free of Segregation of Duties risks.

 

Access control and cyber security considerations

When assigning access in S/4 HANA whether users require direct access to the HANA database for reporting capabilities will need to be considered. If this is required then the HANA privilege concept needs to be included in the security design and the security administrators and developers upskilled accordingly.

 

There are also non-application security considerations that are more prevalent with S/4 HANA than they have been in the past with SAP systems. The introduction of Fiori means that SAP systems can be accessed from mobile devices in a way that was never possible in the past. This offers great flexibility to users and particularly senior management who may only log-in to SAP occasionally to provide approvals.

 

However, introducing mobile devices into the connected landscape widens the attack surface of the SAP estate and therefore requires that the appropriate controls are in place to manage this, such as the use of a mobile device management (MDM) solution to enforce security standards across the workforce.

 

It also means that the S/4 HANA system is likely to have more ports open to the Internet and more inbound connectivity, which means that cyber security needs to be prioritised more so than in the past. Firewalls need to be appropriately configured, security parameters should be in line with best practice guidance and the network architecture must be designed with security in mind.

 

In summary

Despite the challenges of migrating to S/4 HANA, the many benefits means that it is rewarding and worthwhile. The increased performance, simplification and enhanced user experience will bring about a wealth of business value and modernise the ERP infrastructure. Rather like the analogy of the swan, it’s important not to be fooled into thinking that simplicity from the user perspective also means simplicity from the setup and implementation perspective.

 

Topics: S/4HANA SAP SAP Projects SAP Security S/4 HANA Security Cyber Security

We would love to hear your thoughts. Please leave a comment.