The following is an extract of the e-Book “Safety First: Security for SAP S/4HANA” by Turnkey Consulting. This very practical guide has been created to help SAP customers understand the new security considerations that come with implementing SAP S/4 HANA.
Many organisations are now making the move to S/4 HANA in anticipation of the forthcoming 2025 deadline. But the move to S/4 isn’t one that should be taken lightly, implementation will require significant investment and commitment. Security in particular is something that should be properly considered throughout implementation. Ensuring that the new environment is clean and secure from day one, is critical in avoiding the need for costly remediation post deployment.
Implementing S/4 HANA can be done in multiple ways, so depending on your organisation’s current situation there are several credible starting points. Each involves a different level of risk and security exposure but generally, we’ve seen three distinct groups.
- First are those companies who don’t already run SAP, for which a fresh “greenfield” implementation will be required. These organisations have many more configuration decisions to make, and will often need to rely heavily on accelerators from both partners and SAP itself during implementation.
- Second are those who are already running SAP. For these firms a “lift and shift” approach to migration is most likely, as many of the design relevant decisions have already been made – including security configuration. Some of this configuration can be trusted, but care should be taken to assess the relevance of these controls within the new S/4 environment.
- Third are those organisations who are already running SAP, but see the move from ECC to S/4 as an opportunity to start over – rethinking the underlying business processes and redesigning the environment from the ground up.
Despite differing approaches to implementation, all three of these groups will likely face similar security challenges, which we’ll explore in this post.
The 5 most common challenges of SAP S/4 HANA security:
1. Critical access and SoD risks may be present in SAP standard roles
SAP has provided 170+ “best practice” roles for SAP S/4 HANA. However, these standard roles are not tailored to individual businesses and their unique circumstances – meaning they are unlikely to provide the highest levels of security. Sensitive access and Segregation of Duties (SoD) risks are likely to be present, given the much wider access to applications and underlying authorisations these standard roles provide.
Unless these roles are segregated into several other technical roles, and the underlying risks are addressed, then your SAP S/4 HANA environment may exposed from day one.
The advice many SAP customers receive is to adapt their current roles to the 170 new roles provided by SAP. However, this approach does not address your sensitive access and SoD risks, as much greater access is granted than necessary. SAP do not know the individual circumstances of each business and the way its teams are structured, so it’s highly impractical for them to split out each and every possible role down to the required steps in a template process.
SAP Fiori complicates things even further. The Fiori interface is designed to simplify the look and feel of SAP activities, improving the overall user experience. SAP professionals often make the mistake of not focusing on this layer – assuming there is no need as it is simply a presentation layer. However, not applying security controls to the Fiori layer may mean direct conflicts with the actual S/4 core. Users may think they have access they don’t have, they may have an overly complex view of application tiles, which may be unnecessary or just error immediately. To maintain consistency through the employee lifecycle, maintenance of a user’s Fiori app assignment also needs to be considered.
2. Redesigning business processes will cause changes in role design
Moving from SAP ECC to S/4 is an opportunity to redesign business processes – one that most organisations will likely take up at some level. However, doing so will impact the way roles are designed.
Changing your business processes and simply “lifting and shifting” your role designs is likely to be a mistake – as the newly redefined processes will require completely redesigned roles. Not redesigning your roles at this stage will more than likely lead to changes being made further down the line – something to be avoided where possible.
In some cases, the new business processes will be mandated through technical changes to the underlying solutions. This might introduce Fiori based fact-sheets applications that reside on the HANA databases or may be due to different technical changes to the data model (transactions or tables removed/replaced) meaning that some important activities in the business are fundamentally amended.
3. Inability to identify or remediate SAP S/4 HANA access risks and SoDs without the right tools
Building roles in SAP S/4 HANA is much the same as in ECC, with very little context of access risk during the build process. So, not having the right tools to identify these risks will mean they are unlikely to be picked up until 12 to 18 months later, following an audit.
But just imagine how much damage could be done in that period.
When your users are given unnecessary levels of access, which contain Sensitive Access and SoD risks, then you’re potentially creating a problem which is very likely to require lots of remediation work further down the line. To avoid this, you should ensure that your roles are clean for the outset of your S/4 HANA project.
4. Process owners do not have a proper understanding of SAP ECC access to benchmark SAP S/4 HANA design
Your process owners for the different functions across your S/4 HANA environment are unlikely to have a proper understanding of the access granted to other users from the previous ECC system. Making it impossible for them to truly understand how clean their roles are.
This means that any SoD risk hidden in your ECC environment may be unwittingly shifted to your new environment. Again, this potentially provides unnecessary access to users. Compounding the problem that is eventually going to need remediating.
5. Lack of role design and controls knowledge or expertise
It’s very apparent that SAP’s standard roles are being recommended as a suitable approach to securing your new S/4 HANA environment. It’s also true that many organisations are provided full access to Fiori in the hope that back-end controls will restrict access where required. In reality though this is unlikely to provide an appropriate level of security – and result in a dreadful user experience, something Fiori is supposed to improve.
Not recognising the need for security throughout implementation has been a common problem in past ERP implementations – resulting in many costly security remediations. Organisations implementing S/4 HANA are at the risk of making the same mistake, focusing on functional elements and neglecting security altogether.
It’s important to remember that, eventually, your users will actually begin to use the new system. And at that point, security and controls will become critical to your business. Particularly considering that data is one of your organisations most critical assets, not factoring in strategies to protect it from the outset would be an ill-advised approach.
At the very least you need to find some way to analyse and validate the suitability of these standard roles to spot where risks might exist. But in an ideal world, you need the right level of expertise involved from the very start of your SAP S/4 HANA transformation to design your roles in the right way.
It’s likely that existing SAP customers will be impacted more by a move to SAP S/4 HANA, especially if you are looking to migrate from SAP ECC. But whatever your starting point, the advice provided in this blog is applicable to any organisation implementing SAP’s new platform. Put the right amount of effort into good role design and access management at the beginning of your project, and avoid facing a much bigger remediation challenge 12 to 18 months later.
Click here to download the complete guide:Safety First: Security for SAP S/4HANA