VMware vShield App is a hypervisor-level firewall that can be used in virtual SAP deployments to provide network isolation and facilitate quick firewall testing of SAP landscapes. SAP landscape consists of multiple SAP products (ERP, CRM, portal etc) with separate production and non-production environments. The non-production systems can be further broken into categories such as development, sandbox, user acceptance testing, training, etc. Each landscape can consist of multiple virtual machines running different SAP databases and multiple application servers. vShield allows these landscapes to be segregated into separate trust zones based on customer requirements. The following diagram depicts what the security zone architecture could look like in a non production landscape example.
You can define security rules based on containers that are VMware vSphere® objects. One such object is a vApp. A vApp is a resource container for multiple virtual machines that work together as part of a multitier application. In the figure above, each zone can be configured as a vApp comprising all the associated virtual machines for a particular SAP landscape. For example, a rule that denies any traffic from inside a vApp to a specific destination outside that vApp applies to all the virtual machines in that vApp. Isolating landscapes addresses use cases like: end users with access to training systems can be protected from accessing the development and QA systems; new developers and project consultants who are coming up to speed in sandbox systems can be isolated from core development environments.
SAP administrators can benefit from vShield App in the following ways:
- Organizing SAP landscapes into vApps and setting policies against these vApps allows administrators to focus on the landscape architecture and remove themselves from details such as IP addresses.
- For SAP, an IP address change does not typically involve any change to the application configuration files—the same can be said of the firewall rules. Once firewall policies have been set against the vApp, creation of a new database and/or application server virtual machine inside of the vApp requires no extra firewall configuration. This is useful as SAP environments can be very dynamic, for example, creation of sandbox and training systems for new project personnel and end users.
- Administrators can easily test the impact of firewall settings to the TCP/IP ports used by SAP. The SAP application uses many TCP/IP ports for communication between end-users and application servers and between application and database servers (these ports are documented at http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/4e515a43-0e01-0010-2da1-9bcc452c280b).
- Database server virtual machines can be isolated from application server virtual machines. While SAP developers mostly work within the SAP development environment, they may need access to the guest OS of the application server to work with interface files (to manage data that is transferred between separate SAP systems or between SAP and non-SAP apps). So developers may be granted access to the application server guest OS but firewall rules can block access to the guest OS of database server virtual machines which is typically restricted to the database and SAP Basis administrator.
- vShield firewall policies apply to all ESXi hosts in the cluster so they are still enforced when a virtual machine is live migrated between hosts or a to a new host in the cluster (assuming that all hosts are protected by running the vShield App appliance).
In the second part of this blog series we will demonstrate how a vApp consisting of a 3-tier SAP landscape can be protected using vShield App.
