General Isolation Zone Architecture

A good best practice for zone isolation is to split your backend infrastructure into three distinct isolation zones. Typically, the three zones are:

Public zone

This zone is exposed to and connected to the internet. IP addresses in this zone are generally publicly accessible from the internet. Servers, while generally protected via various security firewalls, receive traffic directly from users out in the internet.

Demilitarized zone (DMZ)

This zone is isolated from the internet and is set up so that only specific servers—those in the public zone—have the ability to send traffic to them. End users, out in the internet wild, have no access to these servers.

Internal zone

This zone is further isolated from the internet. No publicly facing servers, even application servers such as those running “frontend services,” have the ability to send traffic to this zone. Only servers isolated in the DMZ, and servers within the application backend, have the ability to communicate with servers in the internal zone.

This infrastructure architecture can best be visualized as follows:

Managing Communications Flow

In the image, you can see the user on the far left, in the wild of the internet, talking to the application frontend services. These services are located in the public zone, which is exposed and visible to the internet. These services—and everything located in the public zone—must be hardened against all ranges of cyberattacks. Typically, the frontend services perform the bare essential capabilities of the application—only those things that need to be handled at the very front. This typically includes account verification, authentication, authorization, load balancing, traffic shedding, etc.

These frontend services talk to transition services located in the DMZ, or demilitarized zone. This zone is a buffer between the frontend, public zone, and the backend, internal zone. For security purposes, only services specifically located in the public zone are allowed to talk to services in the DMZ. No end user can communicate directly from the public internet with services in the DMZ. Services in the DMZ typically perform translational and transitional processes, converting calls from frontend services to calls that can be executed by backend services.

These DMZ transition services call the appropriate backend services in the internal zone, or backend zone. Here, in the heart of the application, services can talk freely amongst themselves, but they only accept commands and traffic that arrive from the transition services in the DMZ. Services in the internal zone have private IP addresses that are not directly accessible from the internet. They do not accept requests that come from the public zone, nor directly from end users.

These zones create safety shields that help isolate traffic from the public internet and prevent mistakes or errors in internal services from accidentally allowing traffic from the public internet to have unfettered access to the backend. Only requests that have been properly vetted by the frontend services, properly processed through the DMZ transition services, can make it to the backend. This triple buffer provides a significant level of system security.