How to Segment Data Center Applications
Prevent malware from moving between applications, between application tiers, and between server tiers.
Segment data center applications to prevent malware from moving between applications and to safely enable those applications for users. Application tiers provide the resources and functions required for data center applications. An application tier consists of multiple server tiers that work together to fulfill requests and commands related to a particular application. Typically, an application tier consists of three server tiers:
Each server tier contains functionally similar servers that work together so that an application tier can present an application to a user.
The server tiers within each application tier create a service chain of VMs. Service chains steer traffic through virtual data center appliances to provide application services. Within an application tier, a web server may communicate with an application server that houses the application code, and that application server may communicate with a database server that houses content. The communication between the three servers, which reside in different server tiers within an application tier, is the service chain.
Data centers contain many application tiers, which may be dedicated to particular departments, customers, contractors, or other groups. Segment the data center application infrastructure to prevent unauthorized and unnecessary communication among application resources and to inspect application traffic.
How to Segment Applications
Segment the server tiers within each application tier by configuring a separate firewall zone for each server tier, so that you can control access to each set of servers and examine the traffic flowing between each server tier as it traverses the firewall. For example, place web servers, application servers, and database servers in separate zones so that traffic between server tiers always goes through a next-generation firewall for full inspection.
Depending on business requirements, you may need to create more than one zone for each application tier to separate tenants, to load balance, to use application tiers for different purposes, to provide different levels of security, or to connect to different sets of servers. Segment the data center to reduce the attack surface of each application tier by grouping in the same zone only servers that require similar levels of trust and that need to communicate with similar application tiers.
Web server tier
Traffic normally enters the data center through web servers, although there are special cases such as IT configuring direct secured access to data center servers for management purposes. As with the other server tiers, create a separate zone for the web server tier so that you can apply granular security policy to it.
Because the web server tier communicates with devices that reside outside the data center, it’s an appealing target for attackers. Place the web server tier on a separate network, for example, using a VLAN. All traffic in and out of the VLAN—all traffic that enters or exits the data center—should traverse a next-generation firewall. You can do this by configuring the next-generation firewall as the default gateway or by using an SDN solution such as NSX to steer traffic.
Segment servers within the web server tier to prevent them from communicating with each other, for example, by using a traditional rule such as NSX Distributed Firewall (DFW) to open a port or block traffic within the tier.
Infrastructure service application servers
Segment the servers that provide critical infrastructure services such as DNS, DHCP, and NTP, and allow access only to their specific IP addresses, using only the appropriate applications.
Allow traffic only to sanctioned DNS servers.
Use App-ID to create application-based whitelist security policy rules that segment applications by controlling who can access each application and on which sets of servers (using dynamic address groups). App-ID enables you to apply granular security policy rules to applications that may reside on the same compute resource but require different levels of security and access control.
Create custom applications to uniquely identify proprietary applications and segment access. If you have existing Application Override policies that you created solely to define custom session timeouts for a set a of ports, convert the existing Application Override policies to application-based policies by configuring service-based session timeouts to maintain the custom timeout for each application and then migrating the rule the an application-based rule. Application Override policies are port-based. When you use Application Override policies to maintain custom session timeouts for a set of ports, you lose application visibility into those flows, so you neither know nor control which applications use the ports. Service-based session timeouts achieve custom timeouts while also maintaining application visibility.
For migrating from a port-based security policy with custom application timeouts to an application-based policy, don’t use Application Override rules to maintain the custom timeouts because you lose visibility into the applications. Instead, define a service-based session timeout to maintain the custom timeout for each application, and then migrate the rule to an application-based rule.
Don’t use next-generation firewalls to segment servers within a particular server tier. When you need to prevent intercommunication of servers within a server tier, use a traditional rule such as NSX DFW to open a port or block traffic within the tier. However, servers within a server tier often need to intercommunicate. For example, a database server tier may be a server cluster that requires free intercommunication.
Recommended For You
Recommended videos not found.