Securing SAP Workloads on AWS: Web Traffic Strategies
December 10, 2024 - Cloud Services - By Luiz Machado
Introduction
At Lynxmind we combine the best practices from both worlds SAP + AWS to design and deploy highly available SAP systems, in a safe and cost-optimized way.
This article provides insights into the architecture of the SAP Web Dispatcher on AWS, showing common patterns and common practices to handle internal requests coming from the corporate network, and external requests coming from the public internet. Additionally, check out how to use a Web Application Firewall to strengthen your security posture when handling external (public) requests
With the support of visual/animated diagrams to better understand the requests flow, the following topics will be discussed:
Note: The focus of this article is to discuss different architectures to deploy the SAP Web Dispatcher using AWS as an example. It is not the intention to point out all the capabilities and detailed configurations of this tool. For more information, check SAP’s documentation .
The SAP Web Dispatcher is located between the Web client (browser) and your SAP system that is running the Web application.
It is the entry point for HTTP(s) requests into your system, which consists of one or more SAP NetWeaver application servers. As a “software web switch”, SAP Web Dispatcher can reject or accept connections.
When it accepts a connection, it balances the load to ensure an even distribution across the servers. SAP Web Dispatcher, therefore, contributes to security and also balances the load in your SAP system. You can use SAP Web Dispatcher in both ABAP and Java systems.
Below are some of the tasks performed by an SAP Web Dispatcher:
Selection of appropriate application server - Persistence with stateful applications, load balancing, ABAP or Java server.
Configuration for multiple systems - You can place an SAP Web Dispatcher in front of multiple SAP systems, and configure which requests go to which system, or perform load balancing across system boundaries.
URL filtering - You can define URLs that you want to be rejected, and by doing so restrict access to your system.
Web caching - You can use the SAP Web Dispatcher as a Web Cache to improve the response times and to conserver the application server cache.
URL rewriting, manipulation of HTTP header fields - The Web Dispatcher can manipulate inbound HTTP requests in general on the basis of defined rules.
Depending on the SSL configuration you can forward, terminate, and (re)encrypt requests.
With this quick recap, let’s talk about our first architectural pattern…
Pattern 1 - SAP Web Dispatcher Architecture for Internal (Corporate Network) Requests
The following diagram illustrates the architecture of a customer network connected to an AWS VPC through AWS Direct Connect.
Note: This is a high-level example to make our case, however, for larger AWS multi-account implementations this would not be the network architecture as you would use separate accounts for egress and ingress traffic for scaling, having a Transit Gateway to manage all connections. Check this AWS blog for more details.
Pattern 1 - Internal Requests
Request Flow:
An end-user sends an HTTP(s) request from the internal corporate network, which is connected to the AWS VPC via AWS Direct Connect.
The internal Application Load Balancer (ALB) receives the request and sends it to the respective Target Group.
The Target Group distributes the load among all SAP Web Dispatchers available (02 servers in this example).
The SAP Web Dispatcher which received the request forwards it to the SAP backend system by using Logon Groups for load balancing purposes in the SAP application layer.
This high-level design represents internal connections coming from the corporate network. However, many customers have the requirement to receive external requests from the public internet as well, and this is what we are going to see in the next pattern…
Pattern 2 - SAP Web Dispatcher Architecture for External (Public) Requests
The following diagram illustrates an external request coming from the public internet.
Note: The DNS (Domain Name Server) part was suppressed in the diagram on purpose. You could use AWS Route53 or whatever DNS tool you use to manage your domains in order to redirect the requests to a certain service to your external Application Load Balancer.
Pattern 2 - External Requests
Request Flow:
An end-user sends an HTTP(s) request from the public internet, and a DNS manager redirects the request to your external Application Load Balancer (ALB).
The external Application Load Balancer (ALB) receives the request and sends it to the respective Target Group.
The Target Group distributes the load among all SAP Web Dispatchers available (02 servers in this example).
The SAP Web Dispatcher which received the request forwards it to the SAP backend system by using Logon Groups for load balancing purposes in the SAP application layer.
In the previous pattern, we’ve seen the architecture pattern for internal connections. This high-level design represents external connections coming from the public internet. However, many customers need to receive internal and external requests in their SAP systems. This is when things start getting complex (and costly)…
Pattern 3 - SAP Web Dispatcher Architecture for Internal and External Requests
The following diagram illustrates the usage of the two first patterns together, where the customer receives requests from the corporate network and from the public internet.
A question that comes up often is: is it mandatory to split internal and external requests into separate Web Dispatchers?
The short answer is: IT DEPENDS 😊. Some customers want to keep internal from external requests separate for security reasons. However, technically speaking, it is possible to place 02 Web Dispatchers in an additional private subnet (called Web Layer, for example) and have both the internal and external Application Load Balancers forwarding the requests to the same Web Dispatchers, this is our next design pattern…
Pattern 4 - How Can I Optimize Resources and Costs (Without Neglecting Security)?
The following diagram illustrates the usage of 02 Web Dispatchers in an additional private subnet called Web Layer and both, the internal and external Application Load Balancers, are forwarding the requests to the same Web Dispatchers, which are called hybrid (just because they receive different types of connections - internal and external).
Pattern 4 - Same SAP Web Dispatcher for Internal and External Requests
This option would optimize your costs since you have 2 Web Dispatchers instead of 4. Consider not only the cost of having more resources up and running but also the cost to operate them (patching, snapshots, configurations, etc).
Now, let’s talk about our last pattern…
Pattern 5 - Using a Web Application Firewall to Handle External (Public) Requests
The following diagram illustrates the usage of pattern 1 (internal requests) and pattern 2 (external requests) but now we include an additional security layer for the public requests: a Web Application Firewall.
What is Web Application Firewall (WAF)?
AWS WAF helps you protect against common web exploits and bots that can affect availability, compromise security, or consume excessive resources.
Pattern 5 - Internal and External Requests + WAF
Request Flow:
An end-user sends an HTTP(s) request from the public internet and a DNS tool to redirect the request to your external Application Load Balancer (ALB).
The Web Application Firewall (WAF) analyses the request based on the Web ACL rules configured and blocks it or forwards it to the External Application Load Balancer accordingly.
The external Application Load Balancer (ALB) receives the request and sends it to the respective Target Group.
The Target Group distributes the load among all SAP Web Dispatchers available (02 servers in this example).
The SAP Web Dispatcher which received the request forwards it to the SAP backend system by using Logon Groups for load balancing purposes in the SAP application layer.
WAF ACL Rules
A web access control list (web ACL) gives you fine-grained control over the web requests that your protected resource responds to.
Here’s a great blog if you want to deep dive into it: Securing SAP Fiori with AWS WAF (Web Application Firewall) - Link
The rules as analysed from top to bottom, and if you add more than one rule to a web ACL, AWS WAF evaluates each request against the rules in the order that you list them in the web ACL.
First, Block By Default
If the request does not match any of the rules, then WAF applies the default act. Set the default to “Block”.
Web ACL rules (high-level explanation)
There are two types of rules: custom, which is managed by the customer and AWS managed rules.
Each customer has its own security requirements, and it should be analysed on a case-by-case basis. The web ACL rule list below gives you a strong starting point for you to secure your SAP services exposed to the public internet.
CustomerIpWhiteList (Custom): Allows access from customers’ specific IP addresses by creating an IP whitelist using set of IP’s.
AWSManagedRulesAmazonIpReputationList (AWS managed): Inspects for IP addresses that have been identified as malicious actors and bots by Amazon threat intelligence.
AWSManagedRulesAnonymousIpList (AWS managed): Inspects for a list of IP addresses of sources known to anonymize client information, like TOR nodes, temporary proxies, and other masking services.
AWSManagedRulesCommonRuleSet (AWS managed): Also known as Core rule set (CRS). Contains rules that are generally applicable to web applications. This provides protection against the exploitation of a wide range of vulnerabilities, including those described in OWASP publications.
AWSManagedRulesSQLiRuleSet (AWS managed): The SQL database rule group contains rules to block request patterns associated with exploitation of SQL databases, like SQL injection attacks. This can help prevent remote injection of unauthorized queries.
AWSManagedRulesKnownBadInputsRuleSet (AWS managed): It contains rules to block request patterns that are known to be invalid and are associated with exploitation or discovery of vulnerabilities. This can help reduce the risk of a malicious actor discovering a vulnerable application.
GeoBlock (Custom): Allow only requests from certain countries (whitelist).
SAPUrlsBlackList (Custom): Block public known SAP url’s by using regex (regular expressions), such as:
/sap/public/icman.*
/sap/public/ping.*
/sap/public/icf_info.*
/sap/wdisp.*
/sap/bc/gui/sap/its/webgui.*
RateLimits (Custom): It defines the maximum number of requests from a single IP address that are allowed in a five-minute period. This value is continually evaluated, and requests will be blocked once this limit is reached.
When it comes to designing your SAP Web Dispatcher architecture (or any other component), it is always about trade-offs. If you have very strict availability and security requirements, then your costs will increase.
We’ve seen the high-level network architecture and respective AWS services for your SAP Web Dispatcher to handle internal requests coming from your corporate network, external requests coming from the public internet and a hybrid scenario, where you have to handle both types of connections.
Then, we’ve seen a more cost-effective architecture, adding a new private subnet and using the same SAP Web Dispatchers to handle internal and external requests (check with your security team if it is OK to handle different connection types in the same Web Dispatcher).
Finally, we strengthen the security posture by adding a Web Application Firewall to inspect external requests before they are forwarded to the Application Load Balancer and SAP Web Dispatcher.
Reach out to us to discover how to optimize your SAP workloads in the cloud!
As the Cloud Services Director at Lynxmind, he brings a wealth of expertise in cloud architecture and strategy, enabling him to lead with a forward-thinking approach to digital transformation. His passion lies in leveraging cutting-edge cloud technologies to drive scalability, enhance operational efficiency, and support the company’s long-term growth and innovation goals.
