Tier application considerations

N-Tier architecture is a technique used by software developers to split components of an application to allow greater flexibility and modularity. This is typically represented by a three-tier architecture consisting of a presentation layer, a logic layer, and a storage layer. We commonly see this architecture used for web applications consisting of web servers in the presentation layer, application and middleware components in the logic layer, and databases in the storage layer.

Security practitioners have adopted the three-tier model for best practices, as it fits well with the principle of least privilege. Granular security controls can be applied to only allow the minimum required network traffic through to each tier. For the web application example, best practices limit all end user traffic to only reach the web servers and only using required services, such as HTTP/HTTPS. Network traffic to the application servers is similarly restricted to traffic from the web servers on specific ports, and traffic to the database servers is only allowed from the application servers to the ports used by the database. In a typical physical data center this is achieved through Layer 3 separation of the tiers (requiring a different subnet for each tier), and firewalls placed between the tiers only allowing the required traffic through, as illustrated in Figure 33.

Figure 33. Traditional three-tiered security architecture

This model is easily configured with VMware NSX. As NSX firewall rules are enforced at the vNICs of each virtual machine, this allows greater flexibility with segmenting virtual machines. Web servers, application servers, and database servers can now sit next to each other within a flat Layer 2 subnet, yet still have granular rules

segmenting them from each other. This can enable easier network organization of Traditional three-

Chapter 6: Network Security compromised from the outside). With NSX, all tiers of an application can be fully containerized to ensure that if an application is compromised by an attacker at any tier, the attacker cannot pivot beyond the application to attack other applications or hosts within the same network zone.

While the three-tier application model is prevalent, there are still applications that are designed to be split into only two tiers. These generally combine the presentation and logic layers into one, while keeping the database tier separate. This is becoming more common in applications developed using languages and frameworks such as Ruby on Rails and certain Python frameworks. In other cases, a web server may only be used for specific capabilities, such as single sign-on, because using a separate server or virtual machine for it would be wasteful.

Frequently an enterprise security team will force the application into a three-tier architecture, often artificially creating a public-facing tier in a DMZ with a reverse proxy for web applications. This can become a source of contention between the security team who are trying to ensure the best possible protection of the data, and the development team who are trying to deliver an application as inexpensively and efficiently as possible. In reality, inflating the application to three tiers and proxying all the traffic through to an application tier doesn’t offer significantly better security. Applying extra controls in the web proxy tier, such as installing the ModSecurity application on top of Apache for additional web traffic inspection can help. In a physical data center where multiple applications are present across network tiers, and databases may be contained in an internal or private zone, having the extra protection against compromise is well warranted.

However, in the cloud, using the capabilities of NSX to containerize applications and limit potential exposure in the event of a compromised application, two-tier

applications may no longer need to be artificially inflated to three tiers. While certain applications with sensitive data may still require the extra protection of the three-tier model, many applications can now be run in two tiers as originally designed without many of the risks associated with bridging network zones. Often the operational issues introduced by the increased complexity far outweigh the enhanced security posture. The containerization enabled by NSX micro-segmentation allows

organizations to implement two-tiered applications in the manner in which they were designed to operate. Figure 34 shows an example of a two-tiered security architecture applied to a virtual application.

Two-tier applications

Chapter 6: Network Security

Figure 34. Example of two-tiered application secured with micro-segmentation

Use case 1: Micro-segmentation with N-Tier virtual applications

Three-tier applications are the most commonly deployed model in enterprises, with each tier requiring specific configuration and changes that can use the NSX capability with vCAC. A three-tier application can be used to demonstrate the network and security provisioning capabilities of NSX when integrated with vCAC. The web tier is external facing and load balanced, serving web pages to users. Each web server needs to communicate with the application server, and the application server in turn

Chapter 6: Network Security An example of a micro-segmentation-enabled three-tiered application is shown in Figure 35.

Figure 35. Three-tiered application implemented with micro-segmentation

As previously stated, many two-tiered applications do not easily lend themselves to being forced to a three-tiered implementation.

NSX security groups and security policies

We configured security groups in the Service Composer section of the Networking & Security web client, as shown in Figure 36. Three security groups were created, one for each application tier, but were not assigned any members, and no dynamic criteria for assignment were configured. vCAC automatically assigns the virtual machines, when provisioned, to the security groups specified in the blueprint. For more details on configuring security groups in a multimachine blueprint, refer to Use case 1: Configure pre-provisioned multimachine blueprint in the Federation Software-

Chapter 6: Network Security

Figure 36. Networking & Security web client view of the security groups

The following security policies, also known as firewall rules, were created for each corresponding security group:

 The web-tier policy allows external connectivity on ports 80 and 443 to virtual machines in the Web Servers security group.

 The application-tier policy allows connectivity from the virtual machines in the Web Servers security group to the virtual machines in the Application Servers security group.

 The application-tier policy allows connectivity from the virtual machines in the Application Servers security group to the database virtual machines in the Database Servers security group.

Chapter 6: Network Security The full rule set is shown in Figure 37.

Figure 37. View of the web, application, and database tier security policies

The completed security policies allow access to virtual machines in the web-tier security group over the HTTP and HTTPS protocols and allow the web-tier virtual machines to communicate with the application-tier virtual machines which, in turn, store and retrieve data from the database tier.

The NSX firewall is a stateful firewall, so when a connection is allowed and a communication session established, the response communication path is also allowed. All other inbound or outbound traffic is denied by the block rules at the end of the rule set. Like a traditional firewall, rules are applied in chronological order, that is, from top to bottom. The security policy is then applied to the web tier security group, as shown in Figure 38.

Chapter 6: Network Security

Figure 38. Web server security policy applied to the Web Servers security group

The final process is the configuration of the multimachine blueprint. In Build Information, the three single-machine blueprints that comprise the multimachine blueprint are shown in Figure 39.

Figure 39. Multimachine blueprint showing single-machine components

Configure pre- provisioned multimachine blueprint

Chapter 6: Network Security In Build Information, each component blueprint is then edited, and the network adapter is mapped to the corresponding security groups, as shown in Figure 40.

Figure 40. Blueprint network and security group configuration

Note: Both the multimachine blueprint and the component blueprints have a Network page,

which may cause some confusion. The multimachine blueprint has a Network page on its main properties screen where the transport zone and network profiles (to trigger dynamic networks) are specified. The component blueprint’s Network page is displayed when you edit the component blueprint in Build Information. The configurable options on this screen are Network Adaptors and Security groups.

The blueprint is published and added to the catalog where it is made available to the finance business group users. Based on the blueprint, vCAC clones the virtual

machines and attaches them to their respective logical switch network segments. It also adds the provisioned virtual machines to the appropriate security groups.

To verify that each virtual machine was placed in the correct security group, check the security group membership in the Service Composer interface of the Networking & Security web client. As shown in Figure 41, the database-tier virtual machine was added to the correct security group and has therefore inherited the firewall rules configured for the database-tier security policy.

Verify pre- provisioned deployment

Chapter 6: Network Security

Use case 2: Micro-segmentation with converged N-Tier virtual

applications

As demonstrated in Use case 1: Micro-segmentation with N-Tier virtual applications, micro-segmentation enables significantly greater control and security. However, we can take this a step further. In many cases, micro-segmentation negates the need for a network segment per tier; therefore, we can implement a converged architecture, as shown in Figure 42.

Figure 42. Example of converged three-tiered application secured with micro-segmentation

The same procedure can be followed to define the security groups and policies. In fact, the same groups and policies can be used. The only difference in blueprint configuration is that you assign the same network profile to the component machine network adapters of the multimachine blueprint. This results in the three tiers being provisioned to the same network segment.

Chapter 6: Network Security

Summary

This chapter outlined the network architecture of the Federation Software-Defined Data Center solution, the design considerations involved, and recommended security practices implemented. This chapter also detailed how the network and security architecture was implemented using NSX for vSphere.

The three-tier application use cases showcased both traditional and converged N-Tier architectures where we enhanced the security posture through the implementation of micro-segmentation. VMware NSX and vCAC offer flexible creation and deployment of workload resources, while providing richer functionality and improved performance over traditional solutions.