Making SAP S/4HANA Secure from the Start

by Tobias Lejczyk, Senior Technology Consultant, SAP SE

 

Everything will change with SAP S/4HANA. This is the feeling many organizations get when they first encounter an SAP S/4HANA project. As with any move to a new technology, the sheer size of the project, the number of people involved, the total hours projected, and the amount of information can be intimidating. In addition, moving to a new technology is always a major disruption, especially for business departments, as it can change the nature of daily tasks.

While navigating a change such as an SAP S/4HANA conversion or implementation can be particularly overwhelming for those who are responsible for the security of their organization’s landscape, this disruption also presents an opportunity — it is easier to change security configurations in an environment that is already disrupted rather than trying to change them during quiet times, where every alteration is met with suspicion and caution. In addition, in an environment where security breaches are a constant threat, project leads are generally keen to ensure the security of the new system and are more willing to accept changes.

What does this mean for security administrators? How do they best take advantage of this opportunity and provide the most secure path forward for an SAP S/4HANA project? As any security administrator knows, a key tenet of security is that you must understand something to secure it. A previous SAPinsider article provided an overview of the critical security areas that need to be addressed with SAP S/4HANA. This article builds on that foundation by looking at what security administrators need to know about securing the infrastructure surrounding SAP S/4HANA — in particular, how to secure browser-based access to the system.

First, the article explains the architectural changes related to SAP S/4HANA that affect security in SAP landscapes, and highlights what hasn’t changed. It then walks through key security considerations related to the HTTP access that is central to the SAP S/4HANA architecture to help security administrators ensure a secure on-premise implementation right from the start.

 

Architectural Changes That Affect SAP S/4HANA Security

At first glance, the SAP S/4HANA core system might not seem very different from an SAP R/3 system or an SAP ERP Central Component (SAP ECC) system (see Figure 1). Similar to the SAP ECC-based SAP Business Suite, SAP S/4HANA is an application that runs on SAP NetWeaver Application Server (SAP NetWeaver AS) ABAP, only SAP S/4HANA is purpose-built for an SAP HANA database to take full advantage of its capabilities.

 

Figure 1 — The architecture of the SAP S/4HANA core system

 

From an application perspective, SAP S/4HANA is a major change from previous ERP applications such as SAP Business Suite. From a security perspective, the settings and considerations related to SAP NetWeaver AS ABAP remain mostly unchanged with SAP S/4HANA. So, what is different about implementing SAP S/4HANA when it comes to security?

To start, the SAP HANA database has been around since 2010, but some SAP customers are only now adding it to their landscapes to support SAP S/4HANA. This means that SAP HANA will be a new system type to manage, with new settings, new architectures, and new security considerations for user management, authorizations, certificate management, and audit logging, for example.

Another new addition is version 2.0 of SAP HANA cockpit, which is an administration tool for the SAP HANA database. This cockpit is based on SAP HANA extended application services, advanced model (often referred to as “XSA”), a Cloud Foundry-based application server that runs on SAP HANA. Version 2.0 of the cockpit introduces a completely new administration environment, which means that in addition to the security considerations mentioned previously, security administrators need to understand the application-specific architecture of the cockpit. In particular, they must be familiar with the microservices setup, application routing, and the specific authentication requirements for attaching the SAP HANA database to this tool.

The architecture of SAP S/4HANA also has a significant impact on security considerations, and perhaps the biggest change compared to SAP R/3 and SAP ECC is the introduction of browser-based end-user access to the system via an HTTP connection. Modern users are accustomed to using browsers on their private desktops, laptops, tablets, and mobile phones, and the events of 2020 have led even more people to use a range of devices while working remotely. When it comes to SAP S/4HANA projects, concerns around browser-based access often arise, as this type of access brings with it all the questions and considerations that come with exposing systems and functionality to the internet (see Figure 2).

 

Figure 2 — The introduction of browser-based access to the system requires new security considerations

 

Enabling browser-based access is a significant change from the SAP GUI access that was prevalent in SAP R/3 and SAP ECC systems. With SAP GUI, it was difficult to securely expose systems to the internet — the infrastructure was not built to support that type of access, and limiting functionality when accessing a system from the internet was nearly impossible. With HTTP-based access, tools and infrastructure exist to securely expose systems to the internet. One of the advantages of browser-based interfaces is they enable more integration between systems and data. Jumping from one system to another is just a click on a link, and integrating information from different systems requires only a simple HTTP call.

The setup and operation of this browser-based access for SAP S/4HANA requires a solid understanding of how HTTP communication works to ensure a secure infrastructure and enable secure communications. We’ll look at the key considerations in these areas next.

 

Creating a Secure Infrastructure for SAP S/4HANA

A secure infrastructure is critical to a secure implementation of SAP S/4HANA. Here, we look at key considerations involved in creating that security, including using network zoning, securing the SAP HANA database, and the importance of establishing good security processes.

 

Using Network Zoning

When installing an SAP S/4HANA environment, one of the first considerations is the placement of the different systems — for example, the SAP S/4HANA system itself, SAP HANA cockpit 2.0, access and integration systems such as reverse proxies, and central routers or SAP Fiori launchpads. A commonly used strategy for ensuring a secure network, and one that SAP has recommended for years, is the use of zones, where systems are placed in different zones based on their criticality and nature, and traffic between those zones is highly regulated. An SAP S/4HANA project is an ideal opportunity to implement this approach, since the project often involves setting up a completely new system, which requires reconfiguring every connection to other systems within the scope of the project, and means that administrators will not have to deal with legacy interfaces.

One of the most significant benefits of zoning is that it enables the ability to distinguish between end users and administrators within the network. There are many types of access that end users do not need, including access to Secure Shell (SSH) ports, direct database access, access to administrative components such as the host agent and instance agent, and direct access to the application server. Primarily, end users access the system via a browser (or in some cases, via SAP GUI), so only ports for the browser or SAP GUI need to be open for them. Distinguishing between end users and administrators within the network provides the ability to easily identify the ports required for end users and include only those on the allow list for end users.

 

Securing the SAP HANA Database

SAP S/4HANA requires the SAP HANA database, which means that those who do not already have it installed must implement it. And since the SAP HANA database holds all an organization’s data, implementing it securely is crucial to setting up the SAP S/4HANA project for success.

Since SAP HANA is a database, the usual security considerations for databases apply for its implementation, including the need to address backup and restore capabilities, user and authorization management, encryption, and high availability. A good starting point for addressing these areas for SAP HANA is the SAP HANA Security Guide. Keep in mind that when it comes to security for a new SAP HANA implementation, many of the considerations are about integration. For example, a backup and restore solution is probably already in place. The same goes for many other areas, such as user and authorization management.

The SAP HANA database can be shielded extensively from end users, since generally only SAP NetWeaver AS ABAP accesses the database. However, in some specific scenarios — for example, to perform an enterprise search — end users might need direct access to the database. This access is usually to the XS engine, which is a small application server within the SAP HANA database. In these cases, access is via HTTP, so only the HTTP ports need to be exposed to the end user. Requests to create end-user accounts within the database are the easiest way to recognize the need for this type of end-user access.

 

Establishing Good Security Processes

One area that is often underestimated in an implementation project is the establishment of good security processes. While security processes are not front and center during the project phase of a solution implementation, during the operation phase, they are critical to maintaining the security of the solution and reacting to any security challenges. This is especially relevant for a core system such as SAP S/4HANA.

It is particularly important to address the following processes to ensure a secure software implementation and operation — and this is true for any software implementation, not just for an SAP S/4HANA project:

• Security patch management

• Security incident management

• User and authorization management

• Disaster recovery as well as backup and restore

Each of these processes represent a critical area of security risk that can undercut the security of the implementation. For these reasons, these processes should be addressed in some form, even if it is only to determine that the process does not yet exist. Identifying the missing process provides an opportunity to decide how to address that process. When it comes to confronting security risks, there are two valid responses: mitigation and acceptance. Burying your head in the sand is not a valid response.

Keep in mind that, as with all security measures, security processes should be designed to enable organizations to work securely, but without hindering business execution. Security is not an end in and of itself. The focus of a company is to do business, and the role of security experts is to enable an organization to operate securely and prevent unwanted incidents, such as data loss and security breaches. For SAP S/4HANA implementations, this means securing the exposure of business functionality and data to the internet to enable anytime, anywhere access.

 

Ensuring Secure Access for SAP S/4HANA

HTTP has been around for decades, and it has become the standard method of accessing systems from the internet. With SAP S/4HANA, browser-based HTTP access to the system takes place primarily through an SAP Fiori interface based on SAPUI5, which is SAP’s UI development toolkit for HTML5. While most SAP administrators are accustomed to the remote function call (RFC) and SAP GUI protocols, the internal workings of HTTP are often less familiar. To help close this gap in understanding, we’ll next take a closer look at the basic concepts administrators need to understand about HTTP.

 

Learning the Basics of HTTP

Understanding HTTP, along with all the advantages and challenges it provides, is key to analyzing and solving problems that can arise around access to the SAP S/4HANA system. Since HTTP applications are often integrated or shared between different browser instances, errors can come from system interactions without any specific error messages. With SAP S/4HANA, this means having a deep understanding of the landscape architecture, the different scenarios and access routes, and the inner workings of the HTTP protocol.

Administrators should be familiar with the basic workings of HTTP as specified in RFC 7230 of the Internet Engineering Task Force (IETF). They should be familiar with what an HTTP request looks like, which attributes are sent, how the attributes are sent, and how a response is to be interpreted. It is also important to understand HTTP state mechanisms, better known as “cookies” (RFC 6265). The entire concept of session management and many authentication processes are built on these mechanisms.

Due to the way HTTP works, however, cookies have their limitations. For example, logon tickets are issued as cookies and may start overwriting each other if they are issued to the same domain by different systems. To resolve these types of issues, it is often necessary to reconfigure cookie issuance, modify cookies, or create custom cookies. In an SAP S/4HANA project, multiple authentication and session-handling methods are typically used, and several different systems are usually involved. It also important to understand how the different mechanisms and cookies interact to ensure a seamless integration and stable functionality.

 

Understanding HTTP Encryption and Authentication

Traffic encryption and secure authentication are part of the baseline for securing HTTP communication. It is no surprise, then, that the topic of encryption and certificate management is of vital importance for any SAP S/4HANA project.

Traffic encryption for HTTP is based on the Transport Layer Security (TLS) protocol. With SAP S/4HANA, administrators need to be familiar with the concept of certificates and their attributes, as well as with the TLS version in use and the cipher suites in use to help secure the TLS connection. In addition to having a conceptual understanding, administrators must configure these concepts in the involved systems.

When it comes to authentication, the most prevalent methods used with SAP S/4HANA — aside from the interaction-heavy username and password approach, which can be a nightmare from a user-experience perspective — are Kerberos, Security Assertion Markup Language (SAML), and client certificates. Each method has its own particular use case:

• Kerberos is used in the customer’s internal network and is very common in Microsoft Windows environments. It can be used for single sign-on (SSO) with SAP GUI as well as for browser-based SSO. It is based on the authentication of the user to the Microsoft Active Directory at the operating system (OS) level, but this means that it is not always readily available for operating systems other than Microsoft Windows, such as Linux, Android, Mac OS, or iOS. In addition, it is not available outside of internal networks, so if the access is happening from the internet, this SSO method cannot be used.

• SAML is an XML-based authentication delegation standard. It is specified primarily for browser-based access, and it is currently the de facto authentication standard for cloud solutions, even as OpenID Connect comes more into play. However, it is important to note that SAML only delegates the authentication to a central SAML 2.0-compliant identity provider, such as the Identity Authentication service from SAP or a third-party identity provider — the user still must authenticate to the identity provider. In addition, it can be difficult to operate a SAML scenario when multiple domain names are involved, because this is not part of the SAML 2.0 specification.

• Client certificates work very well for authenticating users when they can be used. Since these certificates must be managed, they cannot be used with unmanaged devices, such as personal devices, or in bring-your-own-device scenarios. In addition, client certificates are exchanged in a TLS handshake, which means that a TLS-terminating reverse proxy must forward the certificates in some way, and not all reverse proxies support this type of scenario out of the box. So, if the reverse proxy is not an SAP Web Dispatcher, some sort of implementation is necessary, depending on the reverse proxy.

For an SAP S/4HANA implementation, all of this means that an overarching authentication scenario must be defined. This scenario usually includes multiple methods of authentication, since not all components support the same methods, and some scenarios — such as cloud scenarios — might require a specific type of authentication. The administrator operating the solution also must have a solid understanding of how all the pieces fit together to enable troubleshooting, configuration, and maintenance of the solution.

 

Staying Up to Date

One of the most challenging tasks that security administrators face is staying up to date with changes in different security measures, requirements, and technologies. Administrators need to keep up with increasingly complex landscapes and sophisticated attacks, and rapidly changing standards and technologies to address related risks. Due to the prevalence of HTTP access, for SAP S/4HANA, staying up to date with changes around HTTP is particularly important.

HTTP 1.0 and 1.1 were specified at the end of 1990, followed by HTTP/2 in 2015, which introduced several new concepts and radical changes. The third version of HTTP is currently in the specification process and will likely bring changes that differ dramatically from the current setup — for example, it will include mandatory TLS 1.3 encryption and a switch from Transmission Control Protocol (TCP) to User Datagram Protocol (UDP) for data transmissions.

To a large extent, it is impossible to keep the HTTP communication setup for SAP S/4HANA completely stable. Browser vendors constantly introduce changes that can break old functionality or introduce new functionality that is incompatible with the existing setup. One recent example is when Google introduced a new way of handling cookies for embedded pages with the Chrome 80 release, where cookies without a SameSite attribute are handled very strictly. This can cause session handling to break on embedded content (see SAP note 2893481).

Minimizing the effects of these changes on SAP S/4HANA implementations requires investing time and resources into staying up to date and addressing issues that arise. For example, the last few years have seen their fair share of critical security bugs requiring immediate attention. Administrators need to frequently assess these and implement in their SAP landscapes the relevant security patches that SAP regularly rolls out. Administrators also need to maintain an awareness of changes that are happening beyond the SAP landscape. SAP uses a wide range of technologies that are developed or specified outside of SAP, and for this reason, SAP customers must look over the rim of the SAP teacup and venture into the wider world of information security. A good way to start is to read blogs and news about security, follow security experts on Twitter, learn about security bugs with “capture-the-flag” games, follow security conferences, and understand the latest security issues that come up.

 

Conclusion

While an SAP S/4HANA project brings with it a range of exciting new features and functionality, the prospect of navigating so much change can be overwhelming. When it comes to ensuring a secure implementation of SAP S/4HANA, there are some new architectures to address, particularly around the SAP HANA database and the browser-based system access approach, but not everything is new. Existing knowledge and previous experience with securing SAP NetWeaver AS ABAP are still valid with SAP S/4HANA, and even though SAP S/4HANA is new, many of the considerations — for example, user and authorization management, disaster recovery, and backup and restore — are the same. By following the principles outlined in this article, organizations can seize the opportunity presented by an SAP S/4HANA project — the chance to implement security right from the start.

 

Tobias Lejczyk (tobias.lejczyk@sap.com) has been with SAP since 2011, working in the area of technical security for most of that time. In addition to many single-topic-focused consulting engagements, he has worked on multiple SAP S/4HANA implementation projects.