Migration to S/4HANA brings myriad considerations for the SAP-driven enterprise, with security at the top of the agenda. With security inherently linked to an improved and consistent user experience (UX) on offer through Fiori, it can be one of the key success factors for migration to S/4.
Far from just an upgrade, the move to S/4 has a significant impact on security and role design for end users. Any organization attempting to tackle HANA’s security challenges must take a methodical approach to keep the business fully protected. Security also cannot be decoupled from the frontend UX, so it will be critical to include this in success criteria for any SAP S/4HANA project.
In this blog, we’ll look at the process behind a successful S/4 migration from a security perspective, broken down into five key stages.
Additional reading: Explore our Security for S/4HANA guide to further understand the new security considerations that come with implementing SAP S/4HANA.
Step 1: Understand your SAP ECC usage data
For those opting for a Brownfield migration approach from SAP ECC, the first stage is to analyze and understand your ECC usage data for any of the business processes that are not going to be fully redesigned as part of the implementation.
Where business processes are being redesigned or opting for a fresh Greenfield implementation, the SAP ECC usage data is still be valuable to help inform on new process designs from a security perspective.
By benchmarking the usage data from your ECC system for business processes that are not being redesigned, you can then begin to map that usage to how it might need to look in S/4HANA.
Establishing this benchmark will provide a framework on which to build your new S/4 environment. In short, you’ll be able to look at your previous usage data and design the new environment to meet the same needs.
This is all the more critical if you're considering a move to SAP S/HANA cloud, which uses Full Use Equivalent (FUE) licensing. FUEs—and consequently, licensing costs—are based on access, not usage, which, if inflated, can result in higher costs as well as weaker security.
Step 2: Assess ECC usage data and align to any retained business processes
Utilizing previous ECC usage data presents a variety of complexities to overcome before it can become a valuable informing tool on future business process designs for S/4.
Firstly, there are fundamental changes to the list of available transaction codes in S/4 when compared against the transaction codes in ECC. Some ECC transactions have been marked as obsolete or replaced in S/4HANA and other functional areas are being consolidated. Attempting to rely on ECC’s existing transaction code role assignments to determine access in SAP S/4HANA is therefore not a viable option and a transaction code remapping exercise is required at a first step.
Secondly, some of the retained business process designs will need to be revised due to the functional changes within S/4, in addition to the transaction code changes. This requires close alignment with Business Analysts and SAP Security teams to understand functional changes to business processes that will consequently require revisions to role designs.
Thirdly, the security design concept within ECC does not accommodate for changes within the new exposed Fiori user interface inside S/4HANA. Although access through SAPGUI can still be retained via WebGUI screens for on-Prem or S/4HANA Private Cloud, there is no GUI access on S/4HANA Public Cloud. If retained, it does not improve the overall UX for end users. Instead, changes will be needed to roles to accommodate for the Fiori App assignments.
Step 3: Assess the fit with SAP’s standard S/4HANA roles
The next step for a Brownfield customer (and the first for a Greenfield implementation) is to look at the S/4 roles delivered as standard by SAP.
With only 323 SAP standard roles in S/4—compared with around 4,000 roles in ECC 6—it’s clear that S/4HANA’s standard roles are not sufficiently segregated to minimize risk. You’ll therefore need to undertake the exercise of splitting out those roles to meet your access requirements.
Where possible, try to understand where the segregation of duties lie across those standard roles and create derivations from the standard list. Failure to do this from the start can mean introducing significant access risks to your new-look SAP landscape. It may also result in higher licensing costs, if you're opting for S/4HANA cloud.
Step 4: Perform a risk gap analysis and create mitigating controls
Even once roles have been split out for greater segregation, it’s likely that some risks will have to be tolerated, often because roles cannot be split down to the appropriate level of granularity without impairing day-to-day operations.
It’s therefore vital to identify where risks exist within certain roles—and to address the risk by putting controls in place.
This is often the case in supporting roles—for instance within the finance function—where high-level access is afforded to users who may only actually need it in the event of others being away from the business. This can afford the user largely unnecessary access across the entire finance function, providing the potential for considerable business disruption. You should determine if these risks need to be accepted in order to maintain continuity when primary users are away.
Where such conflicts are identified, mitigating or compensating controls must be designed and implemented accordingly.
Step 5: Evaluate the impact of SAP Fiori
A final security consideration of your S/4HANA migration is the impact of SAP Fiori—SAP’s new primary user interface for S/4.
Due to the architecture of the new technology, security of the user interface itself must now be taken into account when designing back-end roles.
SAP delivers standard Fiori content and Fiori catalogs. Catalogs essentially provide access to the Fiori applications, requiring security teams to map the catalogs to the appropriate roles.
As a result, security teams are having to take on double the amount of role maintenance; transaction codes, authorization objects, and Fiori Apps.
Many service integrators do not tackle this challenge effectively and default to recommending the implementation of the SAP standard business roles rather than adopt a security-by-design approach.
While this might sound good in theory—and indeed may work adequately in the short term—problems will soon be encountered as users start to move around the business. The problem is that the standard roles provide a wide range of access across too many Fiori Apps, which would otherwise be segregated if an organization’s security team followed best practice SAP security design concepts.
That’s because unless you’re continuously maintaining the back-end roles, individuals who change position or role within the organization may find themselves gradually exposed to more and more Fiori apps, without intended authorization.
It’s the price you pay for leaving the Fiori floodgates quite literally open.
To guard against this scenario, teams must not only appropriately assign the Fiori catalogs and apps to back-end roles as part of the migration process but put processes in place to ensure back-end roles are properly maintained going forward.
Summary
The user experience is a key success criteria driving organizations to migrate to SAP S/4HANA, however this comes with considerable implications for security, role design, and user access. With the potential costs of data loss, theft, and business disruption at an all-time high, those implications demand some serious thought. Moreover, the business case for optimized security could not be stronger for those moving to S/4HANA cloud as it directly impacts licensing costs.
Naturally, any move to S/4 will bring its own unique challenges. But by following the five pragmatic and practical steps above, you can ensure the robustness of your SAP set-up—allowing you to explore the business benefits of HANA, without exposing the organization to increased risk.
Additional reading: Explore our Security for S/4HANA guide to further understand the new security considerations that come with implementing SAP S/4HANA.
