Many companies deploying SAP systems run business processes that incorporate credit card payment transactions. Credit cards are subject to strict security standards developed by the PCI Security Standards Council, which is a consortium of the largest international payment card issuers. These standards require security settings within the SAP application and in the case where SAP is deployed on the VMware SDDC, PCI standards affects the VMware layer with requirements such as “Install and maintain a firewall configuration to protect cardholder data”. This is addressed by micro-segmentation which makes the data center network more secure by isolating each related group of virtual machines onto a distinct logical network segment, allowing the administrator to firewall traffic traveling from one segment of the data center to another (east-west traffic). This limits attackers’ ability to move laterally in the data center.   Micro-segmentation is powered by the Distributed Firewall (DFW) – a component of NSX. DFW operates at the ESXi hypervisor kernel layer and offers control at the vNIC level, which is very close to a guest VM operating system without being in the operating system.

For SAP micro-segmentation means we can create flexible security policies that align to: the multi-tier architecture of an individual SAP system (presentation, application and database tiers); the landscape of the SAP environment (separate production from non-production). The diagram below shows a SAP micro segmentation example based on the Netweaver ABAP stack with a backend database. The different tiers/components of the SAP architecture are:

• Presentation tier – in this example I am using the SAP client “SAPGUI” to access the application tier. (note: customer environments would include  browser based access, load balancers and a web tier)
• Application tier – application servers based on the Netweaver ABAP stack
• Central Services / Global Host – handles SAP locking services, messaging between the app servers and a NFS share required by all the application servers
• Database tier – services are database dependent
• The components are isolated into their own NSX security groups. A NSX security group, in this example (other classifications are possible), is a definition in NSX and corresponds to a logical grouping of VMs within which there is free communication flow. Communication flow in/out of a security group from/to another group depends on the firewall rules.

Security policies in the above design provide the following controls:

• Controlled communication path limited to specific services and protocols between tiers
• External access only permitted to the application tier via the SAP presentation service
• Access between application and database VMs via specific database services
• SAP services ports vary depending on the “Instance Number” assigned to the application servers and Central Services. Some values are shown here.
• In this example I have included external access from a monitoring tool – vRealize Operations (vROps) with the  Blue Medora  SAP Management pack. This needs access to the application tier via certain ports.

The top right of the diagram above shows a NSX screenshot of the security group definition for the application tier – it shows how VM membership can be dynamically assigned to a security group, for example based on the VM naming convention. This way you can provision new application server VMs and the new VMs will automatically inherent the security policies of the application tier security group.

The following diagram shows the high level architecture that makes all this happen.

The following screenshot shows an example configuration of the NSX communication paths based on the micro-segmentation design shown above (note: actual implementations will differ based on customer security requirements).

You can see a recorded demo of the configuration at the URL below. The demo starts in vRealize Operations where the Blue Medora SAP Management Pack has been configured to monitor the SAP system. Data collection fails due to activation of the NSX firewall.  The NSX configuration is shown and tested and the services are configured to re-establish communication between vROps and the SAP system.

DEMO URL: https://www.youtube.com/watch?v=qdPhejVCG3s&t=82s&index=1&list=PLCED9FDF31C7C0562

****** THIS BLOG IS POSTED ON BEHALF OF THE AUTHOR NELSON YAN *******

At VMworld EMEA in October 2016, we announced the VMware private cloud solution for SAP and the upcoming release of our Adapter for SAP Landscape Management. To read more about the announcement by my colleague Alberto Farronato, check out his blog post here.

Our mission is simple – to provide best-in-class software-defined infrastructure solution that simplifies deployment and management of SAP landscapes so business can focus on innovation instead of “keeping the lights on”.

By virtualizing the SAP environment, the private cloud solution for SAP removes the pains and constraints of running SAP on hardware-defined infrastructure: lack of scalability, high TCO, low business continuity during maintenance, and many more. Furthermore, we can now drive more automation and intelligence in the software-defined infrastructure once SAP has been re-platformed VMware virtualized infrastructure.

With that said, I am excited to announce the general availability of VMware Adapter for SAP Landscape Management version 1.4! The Adapter will radically simplify how SAP basis admins manage and deploy SAP landscapes and more tightly integrates SAP Landscape Management with underlying VMware virtualized infrastructure.

The all new VMware Adapter for SAP Landscape Management

Our latest iteration brings new capability and support that help customers address the challenges around digital transformation for both SAP and VMware.

• SA-API – give programmatic ability to provision SAP landscape and underlying VMware infrastructure
• Integration with vRealize Automation – allow basis Admin to leverage SA-API to create templates that end users can consume and self-provision SAP landscapes

The new features augment the existing capabilities of the adapter, taking automation and self-service to the next level so SAP basis admin can focus on value-adding innovating tasks instead of “keeping the lights on” operations. However, let’s not forget the key existing capabilities of the adapter:

• Provisioning – System Cloning, Copying, and System Refresh
  • Automate key SAP basis provisioning task such as system cloning, copying, and system refresh directly in vCenter with SAP Landscape Management.
• Operations – SAP Hosts, Storage, and Network Migration
  • Migrate VM, switch its data set and network to stand up SAP hosts, move environments, and deploy disaster recovery solutions – all through the SAP Landscape Management interface.

For customers interested in deploying the Adapter in production SAP landscapes, we are also introducing the option to purchase Production-level support from VMware GSS.  Enterprises can now virtualize SAP with confidence, knowing that they have the backing of both SAP and VMware. Support is optional, and the free community edition of the Adapter continues to be available for non-production environments.

But there’s more… SAP Solution Guide!

In addition, we have also been putting together a comprehensive solution guide on how to install, deploy, and manage an SAP environment on top of VMware SDDC. The guide captures the essence of VMware private cloud solution for SAP, which defines the software stack to virtualize, secure and automate SAP environments leveraging VMware’s software-defined architecture. Key topics include:

• Best practice for deploying SAP HANA on VMware vSphere
• Implementing SAP Solutions on VMware products such as vSphere, vSAN, and NSX

The guide is an invaluable resource to help you take the first step in virtualization your SAP environment!

Interested to Learn More?

Visit the VMware Adapter for SAP Landscape Management Product Page

Read the SAP Solution Guide