Securing SAP Workloads on AWS: Web Traffic Strategies

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.

---

What is SAP Web Dispatcher and its use?

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 conserve 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.

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.

Request Flow:

1. An end-user sends an HTTP(s) request from the internal corporate network, which is connected to the AWS VPC via AWS Direct Connect.
2. The internal Application Load Balancer (ALB) receives the request and sends it to the respective Target Group.
3. The Target Group distributes the load among all SAP Web Dispatchers available (02 servers in this example).
4. 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.

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.

Request Flow:

1. 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).
2. The external Application Load Balancer (ALB) receives the request and sends it to the respective Target Group.
3. The Target Group distributes the load among all SAP Web Dispatchers available (02 servers in this example).
4. 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.

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.

Now you have: 2 load balancers (internal/external) + 2 Internal WeDisp + 2 External WebDisp

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.

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).

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).

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.

Request Flow:

1. 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).
2. 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.
3. The external Application Load Balancer (ALB) receives the request and sends it to the respective Target Group.
4. The Target Group distributes the load among all SAP Web Dispatchers available (02 servers in this example).
5. 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 are 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.

• CustomerIpWhiteList (Custom): Allows access from customers’ specific IP addresses.
• AWSManagedRulesAmazonIpReputationList (AWS managed): Inspects for IP addresses identified as malicious.
• AWSManagedRulesCommonRuleSet (AWS managed): Generally applicable to web applications (OWASP).
• AWSManagedRulesSQLiRuleSet (AWS managed): Blocks SQL injection patterns.
• GeoBlock (Custom): Allow only requests from certain countries.
• RateLimits (Custom): Defines the maximum number of requests from a single IP.

Check AWS’s official documentation for more information.

Final Thoughts

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.

Reach out to us to discover how to optimize your SAP workloads in the cloud!