(Jana Subramanian serves as APJ Principal Cybersecurity Advisor for Cloud Security and a Fellow of Information Privacy (FIP), awarded by the International Association of Privacy Professionals (IAPP). In this role, Jana supports strategic customer engagements on cybersecurity, data privacy, multi-cloud security integration architecture, contractual assurance, audit, and compliance.)
Introduction
As enterprises deepen their reliance on cloud services for various business functions and workflows, there is a greater urgency to deploy enhanced cybersecurity measures. A paramount challenge in today's landscape is developing an architecture that ensures secure data transfers between on-premises infrastructures, cloud environments, and third-party SaaS applications.
In this blog, we will delve into the security of the data flow and connectivity of SAP cloud ecosystem. We will place a particular emphasis on RISE with SAP S/4HANA Cloud, Private Edition and SAP's Business Technology Platform (BTP) and SaaS. These platforms provide a plethora of services tailored to ensure secure and efficient integrations between on-premises and cloud SAP ERP systems, PaaS, and SaaS applications. Reference have been provided where applicable to enhance your understanding.
Secure Connectivity to Cloud Services:
The table below offers a high-level overview of secure connectivity options applicable to SAP S/4HANA Cloud, Private Edition, SAP Business Technology Platform, and other SAP SaaS services that can be considered.
Secure Data Flow for SAP S/4HANA cloud, private edition
In the "RISE with SAP S/4HANA Cloud, Private Edition (PCE)" setup, each customer gets a unique subscription on Azure, an "Account" on AWS, or a "Project" on Google Cloud.
The landscape is managed by SAP Enterprise Cloud Services (ECS), and customers do not have access at the infrastructure layer of the hyperscale provider.
Within each subscription or account or project, a VPC/VNET is created, encompassing distinct subnets protected by network security groups or security groups assigned for the Gateway, Application Gateway, Admin, and Production areas.
Additional subnets for non-production can be created upon customer request. The admin subnet maintains Customer Gateway server, with services such as DNS, Internet Proxy, and Source NAT among other functionalities. The Application Gateway subnet, designed to protect incoming internet traffic, contains an Azure Application Gateway associated with a Web Application Firewall. Although Azure setup is shown for illustration, comparable setup is used for AWS and Google Cloud.
External Inbound Internet Traffic to SAP S/4HANA Cloud, Private Edition
Outbound Traffic to SAP Business Technology Platform
Inbound HTTPS Traffic from a Dedicated Network or IPSEC VPN
External Outbound HTTPS Traffic to Internet
Outbound non-HTTPS traffic
Inbound SAP GUI (Non-HTTPS) and SAP Fiori (HTTPS) Traffic
Managed Firewall Services in SAP S/4HANA cloud, private edition
Some of the regulated customer require a managed firewall service to have enhanced security and visibility of the traffic the PCE landscape. In order to support such an enhanced requirement SAP ECS has launched "Managed Firewall Service" for Azure recently and this is applicable only for SAP S/4HANA cloud, private edition, Tailored Option (PCE Tailored Option). This service delivers full support for SPI-based packet filtering. This has paved the way for improved landscape security, achieved primarily through deep packet inspection using IPS. There is also an enhanced mitigation of attack vectors as the system now actively scans for known bot activity. This greatly helps companies to find it easier to align the PCE Landscape with compliance frameworks such as PCI DSS. Alongside these features, there has been a notable enhancement in the traffic flow control within the PCE landscape. Please contact your Cloud Architect Advisory (CAA) in your region for details.
Secure Integration Flow between SAP Success factors and SAP S/4HANA cloud private edition
You can refer to Integration Scenario Finder for Employee Central Integration with SAP S/4HANA On Premise or SAP ERP Systems for integration related to various business use case scenarios.
Secure Integration Flow between SAP Success factors, SAP Concur and SAP S/4HANA cloud private edition.
Secure Data Flow between SPA Ariba and SAP S/4HANA cloud, private edition
References:
Conclusion
This blog is an attempt to provide a summary of secure data flow and connectivity with SAP cloud services. As organizations evolve and embrace digital transformation, a security is only as strong as its weakest link. When integrating platforms such as SAP S/4HANA Cloud, private edition, with SAP SuccessFactors, SAP Ariba, SAP Concur and other SaaS solutions ensuring a secure data flow is paramount. Every interface, whether inbound or outbound, possesses inherent risks. Defining trust boundaries meticulously and assessing threats with robust security measures is essential. While seamless data integration enhances operational efficiency, the secure data flow cannot be compromised. In an era where cyber threats are escalating, ensuring data flow security is more than just a technical requirement — it's fundamental for business success.
Acknowledgment:
The author would like to express deep appreciation for Roland Costea, Chief Information Security Officer, SAP Enterprise Cloud Services and Manoj Nair, Principal Cloud Architect Advisory for their efforts in reviewing the content and providing valuable feedback.
Disclaimer
© 2023 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.
Introduction
As enterprises deepen their reliance on cloud services for various business functions and workflows, there is a greater urgency to deploy enhanced cybersecurity measures. A paramount challenge in today's landscape is developing an architecture that ensures secure data transfers between on-premises infrastructures, cloud environments, and third-party SaaS applications.
In this blog, we will delve into the security of the data flow and connectivity of SAP cloud ecosystem. We will place a particular emphasis on RISE with SAP S/4HANA Cloud, Private Edition and SAP's Business Technology Platform (BTP) and SaaS. These platforms provide a plethora of services tailored to ensure secure and efficient integrations between on-premises and cloud SAP ERP systems, PaaS, and SaaS applications. Reference have been provided where applicable to enhance your understanding.
Secure Connectivity to Cloud Services:
The table below offers a high-level overview of secure connectivity options applicable to SAP S/4HANA Cloud, Private Edition, SAP Business Technology Platform, and other SAP SaaS services that can be considered.
| S.No | Source | Target | Connectivity | Remarks |
| 1 | On-Premises | RISE with SAP: S/4HANA cloud, Private Edition |
| |
| 2 | On-Premises | RISE with SAP: S/4HANA cloud, Private Edition |
|
|
| 3 | On-Premises | RISE with SAP: S/4HANA cloud, Private Edition |
|
|
| 4 | On-Premises | RISE with SAP: S/4HANA cloud, private edition |
|
|
| 5 | On-Premises | RISE with SAP: S/4HANA cloud, private edition via customer owned Hyperscale provider subscription. |
|
|
| 6 | Customer owned Account (AWS)/Subscription (Azure) and Project (GCP) | RISE with SAP:S/4HANA cloud, private edition |
|
|
| 7 | Customer owned Virtual WAN (vWAN) in their subscription. | RISE with SAP:S/4HANA cloud, private edition |
|
|
| 8 | On-Premises/RISE with SAP S/4HANA cloud, private edition | SAP Business Technology Platform |
|
|
| 9 | Services in SAP BTP | Customer owned Subscription/Account in Hyperscale provider |
|
|
| 10 | SAP Business Technology Platform | SAP SaaS applications such as SAP SuccessFactors, SAP Ariba, SAP Concur, SAP S/4HANA cloud, public edition etc |
|
|
| 11 | On-premises | SAP SaaS |
|
|
Secure Data Flow for SAP S/4HANA cloud, private edition
In the "RISE with SAP S/4HANA Cloud, Private Edition (PCE)" setup, each customer gets a unique subscription on Azure, an "Account" on AWS, or a "Project" on Google Cloud.
The landscape is managed by SAP Enterprise Cloud Services (ECS), and customers do not have access at the infrastructure layer of the hyperscale provider.
Within each subscription or account or project, a VPC/VNET is created, encompassing distinct subnets protected by network security groups or security groups assigned for the Gateway, Application Gateway, Admin, and Production areas.
Additional subnets for non-production can be created upon customer request. The admin subnet maintains Customer Gateway server, with services such as DNS, Internet Proxy, and Source NAT among other functionalities. The Application Gateway subnet, designed to protect incoming internet traffic, contains an Azure Application Gateway associated with a Web Application Firewall. Although Azure setup is shown for illustration, comparable setup is used for AWS and Google Cloud.
Figure 1: RISE with SAP S/4HANA cloud, private edition Landscape
External Inbound Internet Traffic to SAP S/4HANA Cloud, Private Edition
- If inbound internet traffic is allowed in SAP S/4HANA Cloud, private edition, it will be inspected by the Azure Application Gateway (AAG) associated with Web Application Firewall (WAF). This also act as Layer 7 load balancer. For AWS, the WAF will be associated with Application Load Balancer and for Google Cloud, Cloud Armour is used which provides protection against application attacks like cross-site scripting (XSS) and SQL injection (SQLi).
- The WAF on the Azure Application Gateway provides centralized protection for web applications, defending against common exploits and vulnerabilities as identified by OWASP.
- The Application Gateway is deployed on a dedicated network subnet and only permits HTTPS inbound connections using TLS 1.2 or higher. The Azure Application Gateway decrypts this traffic and then re-encrypts it before sending it to the backend. For more information on the capabilities of the Azure Application Gateway and Web Application Firewall, please refer to the Azure documentation. Some customers prohibit inbound traffic to this landscape; thus, AAG/WAF will not be activated to meet this requirement.
Figure 2: External Inbound Internet Traffic
Outbound Traffic to SAP Business Technology Platform
- In many integration and extension scenarios, SAP S/4HANA Cloud, private edition, require communication with the SAP Business Technology Platform (SAP BTP) to utilize the services it provides. While SAP BTP is generally accessible only via the internet, a mutual TLS 1.2 authentication is set up between the SAP Cloud Connector, in the PCE landscape, and the connectivity service layer of SAP BTP to ensure a secure mTLS 1.2 tunnel connection.
- Outbound traffic to Internet from the private edition landscape is channeled through the "Internet Proxy" deployed in the Admin Subnet. Additionally, the outbound URL directed to SAP BTP can be explicitly “allow list” within this Internet Proxy. While the diagram illustrates the configuration for AWS, similar deployment setups apply to Azure and Google Cloud.
Figure 3: Outbound Connectivity to SAP BTP
Inbound HTTPS Traffic from a Dedicated Network or IPSEC VPN
- The Figure:4 below shows the data flow for traffic from on-premises to RISE with SAP S/4HANA Cloud, private edition landscape. Connectivity to the RISE platform can be established using dedicated network connections such as Azure ExpressRoute (Azure), AWS Direct Connect (AWS), or Cloud Interconnect (Google Cloud). Alternatively, a highly available site-to-site IPsec tunnel can be established.
- The traffic from the on-premises hit the Standard Load Balancer (SLB) via dedicated network or IPSEC. The diagram shows how Azure Standard Load Balancers (SLBs) enable seamless access from a customer's on-premises. Operating at Layer 4 (transport layer), the SLB supports TCP, HTTP, and HTTPS protocols. An SLB, with its load balancing rules, can serve both the production and non-production member pools throughout the entire landscape. For SSL termination, it is recommended to rely on the backend pool members of the SLB, such as the web dispatcher.
- Additionally, servers should also house the certificates associated with load balancer hostnames. In a response to inbound traffic, the application outbound traffic will traverse via Web Dispatcher and Load Balancer. When outbound traffic initiated by the application, the traffic can traverse directly via dedicated connection without going via Web Dispatcher and Load Balancer. The disaster recovery region should also adopt a similar SLB configuration. The setup is similar for AWS and Google Cloud platform for inbound HTTPS traffic. In general, non-https traffic is not allowed inbound to SAP S/4HANA cloud, private edition (with the exception of SAP GUI).
Figure 4: Inbound Connection from Dedicated Network
External Outbound HTTPS Traffic to Internet
- Customer instances in the SAP S/4HANA PCE production subnet includes systems like SAP Cloud Connector, SAC Agent, have the capability to make outbound “https” accesses to the internet. This is facilitated by the Internet Proxy, which comes pre-installed on the Customer Gateway Server (CGS). This proxy specifically supports only the “https” protocols.
- This security measure in place ensures that only the Internet Proxy can initiate http(s) communication to the internet, effectively blocking direct connections from customer servers. For any specific access needs, customers are required to provide a list of URLs that should be “allowed” (allow list) on the Internet Proxy. As a part of the setup, the Internet Proxy comes with a predefined “allow list”, which is tailored to connect to various SAP SaaS offerings.
- This includes platforms like SAP BTP, SuccessFactors, Ariba, Fieldglass, the Service Marketplace, and connections to the SAP Support Hub. The “allow list” can be adjusted based on customer needs during the project phase.
Figure 5: External Outbound Internet
Outbound non-HTTPS traffic
- When an SAP S/4HANA PCE hosted in Azure initiates a non-https request such as SFTP, it is processed through the Azure Virtual Network and directed to a dedicated Azure Standard Load Balancer (SLB) configured for outbound access. This SLB employs Source Network Address Translation (SNAT) to convert the SAP system's private IP to its public-facing IP. It is important note that any routing or connection rules must be defined using specific source and destination IP addresses rather than hostnames.
- The external system sees the request as originating from the SLB's public IP, processes it, and responds back to that IP. The SLB, using its NAT table, then reverses the SNAT process, routing the response back through the Azure Virtual Network and ultimately to the SAP S/4HANA system. To maintain clarity and manageability in this setup, separate Azure SLB instance is used specifically for outbound traffic, distinct from any instances serving inbound traffic. Additionally, for Disaster Recovery purposes, an additional outbound SLB is required at the DR region to ensure continuity and resilience.
Figure 6: Outbound non-HTTPS connection
Inbound SAP GUI (Non-HTTPS) and SAP Fiori (HTTPS) Traffic
- When an end-user interacts with SAP GUI, the request is transmitted over the local corporate network, passing through organizational security measures. SAP GUI traffic is a TCP traffic and would pass through a dedicated network connection or IPSEC tunnel. This is then directed to application server which in turn passes the request to SPA HANA in production subnet. As this is non-HTTPS traffic, the network load balancer is not involved in the path. It is important to note that WEBGUI will not be enabled for SAP S/4HANA cloud, private edition.
- As an additional note. for the generation of short-lived X.509 certificates, the SAP Secure Login Service for SAP GUI has transitioned from depending on server operating on an SAP NetWeaver Application Server Java. The server capabilities for enrolling X.509 certificates have now been migrated to a cloud service. It is possible to use your current identity provider solution, whether it's SAP Identity Authentication Service or a corporate identity provider like Microsoft Azure AD, Okta, among others. You can refer to SAP Secure Login Service for SAP GUI for more details.
Figure 7: Inbound SAP GUI (Non-HTTPS) and SAP Fiori (HTTPS) Traffic
- When a user interacts with SAP Fiori to access SAP S/4HANA Cloud, private edition, the user request begins at the SAP Fiori Client, either through a web browser or mobile app. This request is then sent over the user's local network, over the internet, or possibly a dedicated connection.
- If the request is directly from the internet, the inbound traffic will be inspected by Azure Application Gateway/WAF before traversing to the Standard Load Balancer, Web Dispatcher, and then being directed to the Application Server. If internet inbound is disabled for the organization, the SAP Fiori request will go via a dedicated network connection (Azure ExpressRoute, AWS Direct Connect, or Google Cloud Interconnect) and then be directed to the Standard Load Balancer before going to the Application Server and then to the backend SAP HANA. For security, this is an encrypted TLS 1.2 encrypted communication integrated with single sign-on solutions.
Managed Firewall Services in SAP S/4HANA cloud, private edition
Some of the regulated customer require a managed firewall service to have enhanced security and visibility of the traffic the PCE landscape. In order to support such an enhanced requirement SAP ECS has launched "Managed Firewall Service" for Azure recently and this is applicable only for SAP S/4HANA cloud, private edition, Tailored Option (PCE Tailored Option). This service delivers full support for SPI-based packet filtering. This has paved the way for improved landscape security, achieved primarily through deep packet inspection using IPS. There is also an enhanced mitigation of attack vectors as the system now actively scans for known bot activity. This greatly helps companies to find it easier to align the PCE Landscape with compliance frameworks such as PCI DSS. Alongside these features, there has been a notable enhancement in the traffic flow control within the PCE landscape. Please contact your Cloud Architect Advisory (CAA) in your region for details.
Figure 8: Managed Firewall Service with SAP S/4HANA cloud, private edition (PCE Tailored Option)
Secure Integration Flow between SAP Success factors and SAP S/4HANA cloud private edition
- In an integration scenario involving SAP SuccessFactors, SAP Business Technology Platform (BTP), and SAP S/4HANA Cloud, Private Edition (PCE), data typically flows from SuccessFactors, triggered by events or new records that require synchronization with SAP S/4HANA in PCE. SAP SuccessFactors uses OData for its API services, enabling seamless data operations such as retrieval and updates.
- This data is then channeled through OData API when integrated with SAP BTP Integration Suite, ensuring secure communication and authentication. As data traverse from SAP BTP to SAP S/4HANA Cloud, PCE, a secure mutual TLS 1.2 authentication channel is established, leveraging both SAP BTP Connectivity Services and the SAP Cloud Connector configured in the PCE environment. As a result, data integrity and security are maintained through end-to-end encryption and rigorous authentication mechanisms across all trusted interfaces.
Figure 9: Secure Integration Flow between SAP SuccessFactors and SAP S/4HANA cloud, private edition
You can refer to Integration Scenario Finder for Employee Central Integration with SAP S/4HANA On Premise or SAP ERP Systems for integration related to various business use case scenarios.
Secure Integration Flow between SAP Success factors, SAP Concur and SAP S/4HANA cloud private edition.
- In the process of integrating SAP BTP Integration with SAP Concur, SAP SuccessFactors, and SAP S/4HANA Cloud, Private Edition (PCE), data is synchronized across these SAP systems. Employee and organizational details flow from SAP SuccessFactors (SF) to both SAP S/4HANA in PCE and Concur. Cost Centre information is exchanged between S/4HANA, SF, and Concur. Expenses recorded in Concur are then posted in S/4HANA, and any compensation changes in SF are reflected in S/4HANA to ensure data consistency.
- When integrating SAP SuccessFactors and SAP Concur, PGP encryption ensures data is scrambled and unreadable before it's sent. This encrypted data is then securely transferred over the network using SFTP, which encrypts the data during transit. SAP BTP acts as an integration layer, facilitating and orchestrating the data flow between SAP Concur and SAP S/4HANA. Using pre-packaged integration flows or custom-designed scenarios on SAP BTP, employee, and expense data from SAP Concur can be synchronized with relevant financial and personnel data in S/4HANA. The data transfer is safeguarded through encryption and secure channels, ensuring that information remains confidential during transit and resistant to potential breaches.
- This secure data flow is paramount for maintaining data integrity, privacy, and regulatory compliance. Only the recipient with the right decryption key can make sense of the data once it's received, ensuring end-to-end security in the entire process. SAP Concur utilizes either Webhooks or RESTful APIs to integrate with SAP BTP. Throughout this connection, traffic is authenticated and encrypted, ensuring end-to-end security.
Figure 10: Secure Data Flow between SAP SF, SAP Concur and SAP S/4HANA cloud, private edition
Secure Data Flow between SPA Ariba and SAP S/4HANA cloud, private edition
- SAP Ariba Cloud Integration Gateway (CIG) facilitates the connection of SAP Ariba solutions to SAP S/4HANA Cloud, private edition. The Ariba CIG leverages the capabilities of the SAP Business Technology Platform integration suite.
- While it is tailored for supply chain and procurement processes, its design simplifies the connection between trading partners and the integration of various SAP Ariba cloud solutions. With predefined message formats and Ariba-specific mappings, Ariba CIG streamlines the configuration and testing of integration processes.
Figure 11: Secure Data Flow between SAP Ariba and SAP S/4HANA cloud, private edition
- The data exchange between SAP Ariba and the Ariba Cloud Integration Gateway (CIG) employs REST APIs, ODATA, SOAP, and Commerce XML. Ariba CIG establishes a secure TLS 1.2 mutual authentication with the SAP Cloud Connector, which is deployed in the SAP S/4HANA Cloud, private edition. This ensures that the entire data flow remains encrypted and authenticated across various trust boundaries.
References:
| S.No | Reference Link |
| 1 | RISE with SAP on AWS Cloud |
| 2 | Integrating Azure with SAP RISE managed workloads |
| 3 | Google Cloud and RISE with SAP |
| 4 | RISE with SAP On-Boarding Resource Center |
Conclusion
This blog is an attempt to provide a summary of secure data flow and connectivity with SAP cloud services. As organizations evolve and embrace digital transformation, a security is only as strong as its weakest link. When integrating platforms such as SAP S/4HANA Cloud, private edition, with SAP SuccessFactors, SAP Ariba, SAP Concur and other SaaS solutions ensuring a secure data flow is paramount. Every interface, whether inbound or outbound, possesses inherent risks. Defining trust boundaries meticulously and assessing threats with robust security measures is essential. While seamless data integration enhances operational efficiency, the secure data flow cannot be compromised. In an era where cyber threats are escalating, ensuring data flow security is more than just a technical requirement — it's fundamental for business success.
Acknowledgment:
The author would like to express deep appreciation for Roland Costea, Chief Information Security Officer, SAP Enterprise Cloud Services and Manoj Nair, Principal Cloud Architect Advisory for their efforts in reviewing the content and providing valuable feedback.
Disclaimer
© 2023 SAP SE or an SAP affiliate company. All rights reserved. See Legal Notice on www.sap.com/legal-notice for use terms, disclaimers, disclosures, or restrictions related to SAP Materials for general audiences.
- SAP Managed Tags:
7 Comments
