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:
- Web server tier—Application interface to users.
- Application server tier—Takes requests from the web server tier to process and generate application functionality.
- Database server tier—Contains data the application requires to function.
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.
| Application Segmentation | How to Segment Applications |
|---|---|
| Application tier | 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. |
| Applications | 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.