Securing SAP with AWS Network Firewall: Part 1 – Architecture design patterns

Introduction

Cloud Security is job zero at AWS. We have a Shared Responsibility Model where customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS services.

A common question that organizations that are new to SAP on AWS ask us, is for guidance on how to build their SAP applications following AWS, partner, and customer best practices guidance. As a mission critical application, SAP workloads must be built and operated in a secure, resilient, performant fashion, while remaining as cost effective as possible. AWS has recently introduced the SAP Lens for the AWS Well-Architected Framework, which describes SAP specific best practices on AWS, across five of the six AWS Well-Architected pillars. One particular area of interest we frequently see, is on security controls for network communications, in and out of the SAP environment on AWS. The SAP Lens provides detailed guidance on how to meet this in “Best Practice 6.1 – Ensure that security and auditing are built into the SAP network design”.

Aligning with this best practice, AWS added a new option with the launch of AWS Network Firewall. Network Firewall simplifies the deployment of essential network protections for Amazon Virtual Private Clouds (VPCs), through a managed service that can scale automatically with the network traffic, so customers don’t have to worry about deploying and managing any infrastructure.

In this first blog post in the series, we will introduce the value propositions for AWS Network Firewall for SAP workloads on AWS, and share recommended architecture patterns for use when securing SAP on AWS workloads.

Value for SAP on AWS customers

AWS Network Firewall has the following features that are beneficial for SAP customers:

• High availability and automated scaling – mission critical workloads like SAP can’t afford to fail due to service failures or variations in network traffic. Network Firewall provides an availability Service Level Agreement (SLA), with a monthly uptime percentage of at least 99.99%.
• Stateful firewall – secure protocols that SAP systems uses.
• Web filtering – further secure SAP Fiori, when in a centralized deployment model.
• Intrusion prevention – an intrusion prevention system (IPS) provides active traffic flow inspection with real-time network and application layer protections.
• Alert and flow logs – integrated with AWS monitoring tools such as Amazon CloudWatch, Amazon CloudWatch Logs, AWS Config and AWS CloudTrail to provide traceability and auditability when it comes to SAP System security.
• Rule management and customization – supports AWS Managed Rules, which are groups of rules based on threat intelligence data, to enable you to stay up to date on the latest security threats without writing and maintaining your own rules. This will benefit customers immediately as it provides the base layer of security for SAP systems. While this can simplify the customer’s responsibilities under the Shared Responsibility Model, it is still important to evaluate if all your security requirements are being met.

Architecture Pattern Overview

The centralized security inspection architecture shown in Figure 1 is a high level view of how the traffic between VPCs and Internet are being inspected by AWS Network Firewall. This will form the basis of the architecture patterns for VPCs containing SAP workloads, which may be customer managed, partner managed, or SAP managed under a RISE with SAP model. This concept also allows the use of multi-account approach based on AWS Security Reference Architecture (SRA) and Inspection Deployment Models with AWS Network Firewall. You will need a Firewall Endpoint in its own VPC and subnet, and this needs to be connected to your Transit Gateway. You then route select traffic through that Endpoint that you want to inspect/block/filter.

Figure 1 – Centralized security inspection architecture for AWS Network Firewall.

North South Inspection Flow:

• NS1 – User from internet accessed through Inbound VPC.
• NS2 – Packet routed to the Firewall Endpoint.
• NS3 – SAP received and answers queries.
• NS4 – Packet routed to the Firewall Endpoint.
• NS5 – Response sent through Outbound VPC.

East West Inspection Flow:

• EW1 – SAP access S3 bucket for backup or interface.
• EW2 – Packet routed to the Firewall Endpoint.
• EW3 – S3 bucket received and answers queries.
• EW4 – Packet routed to the Firewall Endpoint.
• EW5 – Response is received by SAP.

To apply the concept, we shall describe the AWS Network Firewall Architecture into 3 patterns for SAP based on its use cases and how the various users and systems traffic flow to and/or from SAP Systems.

• Internal Access.
• Internet egress access.
• Internet ingress access.

We will describe in detail the patterns in the subsequent sections.

A1. Architecture design pattern for internal access

In this scenario, the SAP applications are accessed through corporate network, where users or applications are connected through AWS Direct Connect or AWS Virtual Private Network.

The Incoming traffic (from on-premises to workload VPC) and outgoing traffic (from workload VPC to on-premises) are being inspected through AWS Network Firewall. Examples for this type of traffic, which flows through secured networks only, are demonstrated in Figure 2. These include:

• SAP GUI to SAP S/4HANA or other related NetWeaver based solutions.
• Web Browser access from internal user to SAP Fiori system.

Figure 2 – Architecture design pattern for internal access.

Traffic flow description:

1. User access SAP S/4HANA from SAPGUI.
2. Network Firewall inspects packet due to Route table.
3. Packet gets routed to Workload VPC.
4. SAP S/4HANA answers queries and responds back.

A2. Architecture design pattern for Internet egress access

In this scenario, the SAP applications are accessing the Internet directly, but we only want to support network sessions that originate from our secured networks.
The outgoing traffic (from workload VPC to Internet) are being inspected through AWS Network Firewall. Examples for this traffic are demonstrated in Figure 3. These include:

• Regular patch updates, such as YaST online update for SUSE Linux Enterprise Server.
• Interfaces that require invocation of web services from on-premises SAP workloads such as SAP S/4HANA to external cloud-based solutions such as SAP Ariba, SuccessFactors, Cloud for Customer, Concur, and other SAP or non-SAP services.

Figure 3 – Architecture design pattern for Internet egress access

Traffic flow description:

1. SAP S/4HANA send data out to internet.
2. Network Firewall inspects packet due to Route table.
3. Packet gets routed to Outbound VPC to be routed to internet..

A3. Architecture design pattern for Internet ingress access

In this scenario, originating network connections from the Internet to our SAP applications based in secure networks. The Incoming traffic (from Internet to workload VPC) and outgoing traffic (from workload VPC to Internet) are being inspected through AWS Network Firewall. For incoming HTTP Protocol, it will be inspected by AWS WAF (Web Application Firewall) as well. Examples for this traffic are demonstrated in Figure 4. These include:

• SAP Support access through SAP Router.
• SAP Business Technology Platform (BTP) interfaces that goes through SAP Cloud Connector.
• Internet/remote users that access SAP Fiori through web browsers.

Figure 4 – Architecture design pattern for Internet ingress

Traffic flow description:

1. User, SAP BTP, SAP Support, Third party access SAP S/4HANA from Internet.
2. Network Firewall inspects packet due to Route table.
3. Packet gets routed to Workload VPC, then SAP S/4HANA answers queries and responds back.

Overall Architecture Design Patterns

The pattern in Figure 5 captures the complete picture of all the architecture patterns above. This architecture also includes possible extensions to another Region through AWS Transit Gateway, should there is a need for further expansion of the architecture (for example in a Multi Region Disaster Recovery).

Figure 5 – Overall architecture design patterns

Cost Consideration

For all elements of your workload, it is important to understand the potential cost impact upfront. We recommend you capture metrics on your current network traffic volumes and use these to calculate the total cost of ownership of implementing the architecture patterns described in this blog post.

You can leverage AWS services and features such as CloudWatch, VPC Flow logs, or third party solutions such as Cisco ThousandEyes and SolarWinds, or existing firewall appliance reporting features to capture these detailed metrics from the real network traffic volumes across your AWS-based and external networks.

With AWS Network Firewall, you pay an hourly rate for each firewall endpoint. You also pay for the amount of traffic, billed by the gigabyte, processed by your firewall endpoint. Data processing charges apply for each Gigabyte processed through the firewall endpoint regardless of the traffic’s source or destination. For more detailed pricing you can refer to Network Firewall Pricing page.

With AWS Transit Gateway you are charged for the number of connections that you make
to the Transit Gateway per hour and the amount of traffic that flows through AWS Transit Gateway. For more detailed pricing you can refer to Transit Gateway Pricing page

Conclusion

We have discussed the architecture patterns when implementing AWS Network Firewall for SAP workloads running on AWS. These patterns cover both internal and external (Internet) access scenarios, and include common use cases for each pattern, along with a description of how the network traffic will flow through the pattern. The patterns are derived from AWS Security Reference Architecture (SRA) prescriptive guidance that leverages AWS Organizations. This architecture can be further enhanced depending on customer requirements such as high availability setup across two Availability Zones, etc.

More information on working with AWS Network Firewall patterns on AWS may be found through the blog posts: Deployment models for AWS Network Firewall, Deployment models for AWS Network Firewall with VPC routing enhancements and Design your firewall deployment for Internet ingress traffic flows.

In the following blog posts in this series, we will dive deeper into using AWS Managed Rules and/or your own rules for Network Firewall with SAP workloads on AWS, as well has the operations aspects of monitoring Network Firewall.

In summary, AWS Network Firewall allows us to secure mission critical SAP workloads against malicious traffic. It is a managed service by AWS, which scales automatically with traffic, it has high availability and high performance that can support critical business applications such as SAP.

You can find out more about SAP on AWS and AWS Network Firewall from the AWS product documentation.