insiderBOOKS Articles and Insights

Security / Cloud

Network Security

Chapter 4 Excerpt – SAP in the Cloud: Security Essentials

Today, most computers are networked by default. You probably connect to the Internet automatically without even thinking much about it. It’s so prevalent that electronic devices that we wouldn’t even think of having networking capabilities 10 years ago now have Wi-Fi enabled from the start. Your car, your kitchen appliances, and even some LED light bulbs now have some sort of networking features built in.

Cloud computing wouldn’t exist without this network saturation. The power of the cloud comes from remotely connecting to a virtual computing infrastructure without noticing the seams between your computer and the cloud. But that network opens up vulnerabilities, so we need security countermeasures based on our risk profiles and known threats. Connections to larger networks, including the Internet, allows for free flow of information, but that freedom can expose your data to bad actors.

When we talk about networks, we mean everything that links one computer to another, both physically and virtually. It’s the fiber optic cables connecting a data center to the outside world, the routers that get traffic where it needs to go, and the security appliances attached to the network. It’s the IP addresses, Domain Name Services (DNS) servers, Virtual Local Area Networks (VLANs), and the host ports that listen for incoming traffic. These make up the networking infrastructure of your cloud environment, up to and including the networking interface card that lets your organization’s employees connect to that cloud . . .

Creating a Defensive Infrastructure

With any cybersecurity defense, you want both a depth of defense and a diversity of defense. When an attacker hits your cloud provider, you want to make that person’s task as complicated and as difficult as possible.

By depth of defense, we mean that you want to have a lot of barriers in the way: multiple routers, firewalls, security appliances, network switches and bridges, and other servers. If they manage to break through one, they still have several more to go. While they navigate barrier after barrier, your detection routines will have more chances to spot them and react.

By diversity of defense, you want different types of roadblocks in place. Not just multiple forms of defense, but brands and operating systems. If you have several routers, make sure they come from different manufacturers. That way, a single flaw in one type of system, equipment, or software won’t leave your entire network wide open.

Depth and diversity apply to software, too. We’ll talk about specifics later, but you want multiple firewalls and detection/protection systems. Using virtual LANs and network segmentation, you can add more levels that a potential attacker has to navigate.


Firewalls are the traffic cops of the network. They operate on OSI layer 3 and let traffic through based on the IP address of the sender and receiver, the port number that the sender or receiver uses, and the transport layer protocol that traffic uses. Protocols include the transmission control protocol (TCP), over which much of Internet traffic travels. A port number is a communication endpoint on a computer. Applications that receive data from networked sources listen for that data to arrive with a specific port number. For example, web servers listen for hypertext transfer protocol (HTTP) traffic over port 80.

When you want to allow certain network traffic, you open the port for that traffic on your firewall. Otherwise, that traffic is blocked, regardless of whether it’s incoming or outgoing traffic. You may have seen a warning on your computer when you first start up a new program: “Firewall has blocked some features of this program” or something similar. That’s a firewall in action. Once you enable and configure the port for that application, that traffic may travel the network to its destination. So long as the destination port is open and configured on the other end, the data transaction can complete.

With your SAP application, it’s the same story. You may need to have your cloud provider open those ports on all firewalls in the network for you. SAP provides a full list of the ports that any of their applications use, as well as those that they will never use.

A firewall can be either network or host based. A network-based firewall can be either a hardware or software solution. They guard against traffic on an entire network. Your routers will often have firewall and port-blocking features to allow fine-tuning of what traffic goes through which gates. Sometimes firewalls can do more than just open or close ports. Advanced firewalls can perform load balancing, proxy services, bandwidth control, content control, and error notification.

Host-based firewalls manage the traffic in and out of a single computer or virtual machine. Host-based firewalls are usually software applications. They only protect the individual system that hosts it from threats. In a cloud platform, each virtual machine could have its own virtual host-based firewall.

Ask any potential cloud provider about its firewalls and firewall policy. Does it have both network and host firewalls? Can you customize the ports or does one of its administrators have to do that? What protection does it have at the front of its network? Does the provider validate firewall settings regularly, and can you be included in that validation activity?

On your end, you should have firewalls protecting networks, systems, and computers that connect to the cloud. Many operating systems come with a firewall by default, but you can purchase other firewall software or appliances to secure your networks. Your IT department can install stronger host-based firewalls or add network-based firewalls to their security portfolio if they haven’t already. Those placements and activities should be based on your own risk profile to protect appropriate systems and data from threats.

Network Segmentation

In order to provide each client with a secure environment isolated from other clients, cloud providers can segment their network into smaller subnets. This process enhances both security and performance, but we’re going to focus on the security aspects. A subnet exists apart from all other servers and traffic on the cloud network, isolated because subnets do not broadcast to the other subnets, nor can they view traffic destined for those subnets.

Providers can use segmentation to frustrate attackers. Potential attackers want the least amount of infrastructure between their source and destination—your data. By separating traffic by risk and function, you can implement the countermeasures that make sense for each stream of traffic.

So how does network segmentation actually work? Primarily, cloud providers segment their networks through network switches, which manage traffic on OSI layer 2, creating VLANs. These switches can route traffic based on MAC addresses, whether real or virtualized, to create networks that operate like a LAN. For virtual machines, the hypervisor comes with a virtual network switch, but that often manages traffic on a single physical server.

In a VLAN, as in a LAN, all connected servers can broadcast their frames to each other; that is, they announce their presence on the network and are easily discoverable. If you’ve used shared folders on a work network, you know that you don’t need to enter an IP address or search for other computers; you can just browse them. For cloud servers, this lets them know which other hardware devices are part of their resource supply. Let’s take a look at how switches can segment a network, shown in Figure 4.2.

Figure 4.2

Figure 4.2 An example of switches segmenting a network

Each switch is configured to pass the traffic to and from servers with specified hardware addresses. Traffic in this case only applies to broadcast frames. You can send normal network traffic, such as ping requests, to these servers if they have a reachable IP address.

In our CMS, each virtual machine has three distinct network segments. One network hosts client-facing—but not necessarily Internet-exposed—traffic, and has all the risks associated with exposed traffic. Another connects to a dedicated internal network segment used only for backup and recovery services. The third is used for CMS administrative services, including service management and resource provisioning.

But won’t connecting all three networks to the same server allow an attacker to jump from one to the other? It might, but this separation requires the attacker to jump through another hoop. Attackers would require a high degree of skill to bridge these connections. Additionally, the hypervisor and virtualization technology prevents any attacker from easily jumping servers. We’ll cover hypervisor security in the next chapter.

Security Zoning

Within your cloud environment, various SAP business objects and processes have different security needs. For example, your database has a higher risk exposure than your client server. Other connected objects may have different risk profiles. Or you may have different SAP systems that correspond to separate business segments. As such, you can set up different levels of security for each of them.

Your cloud provider will usually give you multiple IP addresses to use. These separate IP addresses can resolve to different parts of your SAP system. On an enterprise system, each of the moving parts in your SAP system will just send data to the server on which they reside. But you can change that.

Here’s where those different security levels come in. Using firewalls, you can create different security zones. Each zone can differ based on what ports and IP addresses are allowed in. In this way, you could isolate your database or storage replication system if you use SAP HANA, so attacks only affect the systems and objects with the lowest impact on your business.

When we set up SAP systems in the cloud, we always segregate them into three zones (see Figure 4.3). The client software—what you and your employees use to perform your work, such as SAP Fiori—connects to a client server. This server is located in what’s called a demilitarized zone (DMZ), a zone that opens to your organization, whether through a VPN or over a private MPLS line. That server connects to an application server through a firewall. That’s zone two, and the software client never touches it directly. Zone 3 is the data storage area, which only allows connections from the application server and our backup software. Because of this zoning, our backup software doesn’t have access to the application or client servers, and vice versa.

Figure 4.3

Figure 4.3 CMS security zoning example

Our setup follows the principle of least access. Any server only has access to the pieces that it absolutely needs to contact in order to function. Everything else is denied. If you have multiple other SAP pieces, a CRM or financial add-on, say, you can separate them into zones as well.

This segmented setup also protects against malicious insiders, disgruntled employees, or people with false credentials who want to do your system harm. By placing your valuable data where no user can directly affect it, you can rely on SAP’s logging and auditing features to track who performs any action in the system.

When you talk with any potential cloud providers, find out what kind of zoning they allow. Do you have to bring your own firewalls or will they set up firewall zones for you? How many internal zones and IP addresses do you get? They should be willing to work with you on any of these questions. But as with any security measures above basic, you may have to pay extra for additional network infrastructure.

To continue reading, please visit the full publication SAP in the Cloud: Security Essentials.

Popular Chapters

View More
  • Chapter 7: Phase Four: Transition

    In the final phase, transition, we go through what you can expect at go-live, followed by lengthy discussions regarding service level agreements, operations process training, and transition to cloud operations. We talk about intricacies of system stabilization and monitoring. Finally, we explore the options for business continuity and security

    Read More
  • Chapter 6: Phase Three: Build

    In the third phase, build, we walk through developing proofs of concept for your project. The chapter discusses how to take advantage of a provision-shared infrastructure, as well as strategies for building and testing that infrastructure. There is an examination on how to build and mitigate databases and applications, as well as planning the phase cutover. It also looks at automated provisioning and automated services.

    Read More
  • Chapter 5: Phase Two: Model

    The second phase of moving SAP to the cloud, model, contains an overview of the second half of onboarding to the cloud. It examples infrastructure requirements and design and walks the reader through the process of developing a workload analysis. The chapter discusses application and business process discovery as well as operational run books and migration strategy.

    Read More
View More