One of the advantages of cloud applications is that you don’t have to take care of security. Which is true – mostly. In reality, while most of the security responsibilities and tasks are taken over by the cloud service provider, there are some things which the customer still holds responsible for. And that also goes for the security responsibilities in SAP S/4HANA Cloud.
Now, the title of this article specifically mentions SAP S/4HANA Cloud, without specifying whether it refers to private or public cloud. This is intentional as the focus is on the customer's responsibilities in the S/4HANA Cloud responsibility model – and in the following I’d like to highlight the responsibilities of the customer in general, while detailing the differences between SAP S/4HANA Cloud Privat Edition versus SAP S/4HANA Cloud Public Edition.
Responsibilities in General
In terms of security, responsibilities are relatively clearly split between the Cloud Service Provider (CSP) and the customer. On a high level, the CSP’s responsibility includes security operations, network application, database management, operating system management, and the bare metal, unless partnering with a hyperscaler.
The customer, on the other hand, is responsible for the application's access and security. However, there's a significant distinction depending on whether we're discussing SAP S/4HANA public or private cloud.
Looking at it from another perspective, as the cloud service provider, we don't have access to your customer data, user identities, authentication, and business processes. The responsibility for these aspects lies with the customer. Conversely, security for the application server, database, operating systems, physical security, and bare metal security falls under our, SAP's, jurisdiction as a cloud service provider.
Understanding the difference is crucial, not just for security, but for adjacent topics as well.
Auditing cloud applications
In order to get an overview, let’s begin with how auditing is approached in different cloud deployment options. This will help elucidate why it's critical to clearly distinguish responsibilities between you as a customer and SAP as the cloud service provider.
When examining IT general controls, one should consider business processes, applications, and infrastructure. These elements require auditing by your auditor. IT application controls relate to business transactions and processes. The software, such as SAP S/4HANA, handles this. However, as the customer, you define the business processes and are therefore accountable to the auditor to ensure these processes function as designed.
Secondly, there are application-related controls. These involve access management, change management, security configuration, and monitoring of application jobs and integration scenarios. The goal here is to ensure the application is implemented securely and correctly to meet the requirements of the business processes.
The same principle applies to IT infrastructure, which must be implemented correctly to support business processes without negative impacts. This includes operating system and database security, but also physical data center security.
Customer Audits
When considering various cloud service models, the scope of the auditor's role varies significantly between on-premise installations and software as a service. In an on-premise model, the customer’s auditor must assess everything from physical security to business process controls.
In an Infrastructure as a Service (IaaS) model, the auditor would need to rely on the cloud service provider for physical data center security and hardware matters. However, everything else, including service operating systems and databases, remains the customer's responsibility and must be audited accordingly.
With Platform as a Service (PaaS), like S/4HANA private cloud, responsibilities for the security of operating systems and databases shift to the cloud service provider.
Software as a Service (SaaS) extends this concept further, in cases like the SAP S/4HANA public cloud, where standardized software is used by all customers.
To manage these varying responsibilities, the SOC (Service Organization Control) report, specifically the SOC 2 report has been established as an industry standard. This report is an attestation from auditors that all controls regarding IT infrastructure and application responsibility are functioning as designed.
The SOC report's purpose is to prevent each customer's auditor from having to verify that a CSP is maintaining their controls correctly.
However, it's crucial to note that customers must request the SOC 2 report regularly from the CSP, review it, and ensure it aligns with their security requirements. Subsequently, the company and its IT auditors need to review the controls within the SOC 2 report to verify everything is in order.
The differences in SAP S/4HANA deployment models
Let's delve into the S/4HANA application, specifically focusing on the differences between private and public cloud options.
To do this, we could proceed alphabetically by topic, but the most effective approach would be through the lens of the SAP Secure Operations Map. This tool, although developed before the advent of cloud technology, remains relevant as it comprehensively covers all tasks required for running applications like S/4HANA.
As a brief overview, the map starts at the top with the organization, which isn't directly related to IT. It emphasizes the need for security governance awareness and risk management - an area that's often overlooked. In essence, it's crucial to identify potential risks, prepare responses, and manage them appropriately.
Next, the secure operations map addresses the application itself, highlighting aspects like access management, authentication, authorizations, and custom code security. It considers all customizations made in your SAP S/4HANA system.
On the system level, the map focuses on security hardening, secure SAP code, our secure development process, and security monitoring.
At the bottom of the map, mirroring the cloud responsibilities we've discussed, there’s the environment. This includes network security, operating system, database security, and client security.
Taking a closer look at this, and returning to the cloud deployment models we discussed earlier, we see that the Secure Operations Map's five topics (environment, system, application, process, and organization) are all the customer's responsibility in an on-premise environment.
In a private environment, the responsibility transitions between SAP and the customer around the application area. In a public environment, we, as the service provider, shoulder a larger share of the responsibility compared to the customer.
Network security is a shared responsibility between customers and SAP, regardless of whether the environment is private or public. As a customer, you must ensure that the network you use to access applications is secure. For instance, in a private environment, you may use SAP GUI via a VPN tunnel to our network. In contrast, in the public cloud, you can only access the software through a web browser over the internet. In both cases, you as the customer need to ensure that the network on your end is secured.
The operating system database security is our responsibility, again, regardless of whether it's a private or public cloud. Client security, on the other hand, such as ensuring the SAP GUI or web browser is set up securely, falls under the customer's domain in both cases.
When it comes to system security hardening, it's our responsibility, fully. Secure SAP code, from a development perspective, is our responsibility in both private and public cloud scenarios. However, there's a key difference when it comes to patch management in the private cloud. Here, updates are individual per customer and may affect business processes or require system restarts. Therefore, we coordinate with you before initiating any updates, unlike in the public cloud, where updates affect all customers.
Security monitoring and forensics represent another shared responsibility, but there are differences between Rise and Grow. In Rise, due to access to most of the ABAP stack, similar to an on-premise environment, you receive more information, including infrastructure logs provided by our private cloud operations team, a service called LogServe.
In a public cloud scenario, we provide a limited number of logs for security monitoring. Some information, technically, is shared among all customers; hence, we can't share it with individual customers.
The application
Let's delve into the application, specifically User and Identity Management.
When we discuss roles and authorizations, we see a distinction between private and public cloud environments. In a private cloud, customers retain access to the PFCG, the SAP system transaction where roles and authorizations are defined and implemented. It's important to note that while you do have PFCG access in the private cloud, it's not usually full access. You typically can't assign authorizations or access the roles and authorizations definition, PFCG, as an admin, particularly when it comes to technical security topics.
In the public cloud, we implement a different strategy. We use what we call business catalogues, the smallest units of roles and authorizations. These catalogues are combined to create roles within the application, aligning with your business processes.
Regarding Custom Code Security, your code is generally your responsibility. However, there's a slight difference between private and public clouds. In the private cloud, you have more opportunities to program additional applications on top of S/4HANA. In contrast, in the public cloud, we provide Developer Extensibility that allows business application extensions but limits access to low level functionality.
The last main topic from within the Secure Operations Map is Processes and Organizations. This is primarily the customer's responsibility, which is why we won’t discuss it here.
Conclusion: Lots and less to think about
As mentioned in the opening of this article: moving to the cloud gives you a lot less to think and worry about, especially when it comes to security. However, it does not relieve customers from all responsibility - something to keep in mind. On the other hand, we at SAP will support now and in the future by guiding customers through those settings they are responsible for. And by making S/4HANA Cloud the most secure ERP system.
- SAP Managed Tags:
