How to Segment Data Center Applications
Table of Contents
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. Allow traffic only to
sanctioned DNS servers. Use the DNS Security service to
prevent connections to malicious DNS servers. |
| Applications | Use App-ID to create application-based allow
list 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.