Maximize your cloud security with isolation zones

Keeping your application safe and secure is critical to a successful enterprise. Whether you use cloud-native application architectures or on-premises systems—or anything in between—it’s generally considered that splitting your infrastructure into security zones is a best practice. These zones provide security isolation that keeps your applications and their data safe from outside bad actors. A security breach in one area can be limited to impact only the resources within that one area.

Done correctly, this zone-based isolation process can take a security breach that might otherwise be a massive impact to your application integrity, and turn it into a much smaller problem, perhaps an insignificant breach with minimal impact.

Understanding security zones

While there are many different ways to architect your security zones, one common model is to use three zones. The three zones provide separation between the public internet (public zone) and your internal services and data stores (private zone), inserting an isolation layer (DMZ) between the two. Figure 1 shows how they work together.

IDG

Figure 1. Services in isolation zones.

Users interact with your application from the public internet by accessing services in the public zone. The public zone is exposed and connected to the internet. Services in this zone are exposed directly to the internet and accessible directly from the internet. The services run on servers that are protected via various firewalls, but otherwise receive traffic directly from users out on the external internet.

These public-facing services do as little work as possible, but one of their more important tasks is to regulate and inspect the data received from the external internet to make sure it’s valid and appropriate. These services should filter denial of service (DoS) attacks, bad actor infiltration, and invalid end-user input.

The bulk of the application exists in the private zone. This zone is where the application data is stored as well as the services that access and manipulate the data, and it’s where the bulk of the back end of your application exists. In fact, as much of the application as possible should be in this zone. This zone is the furthest away from the public internet. There are no public-facing servers in this zone. The zone is as isolated from the public internet as much as possible.

To keep the private zone secure, nobody can access the services in this zone directly. Even services in the application’s public zone cannot access services in the private zone. Instead, services in the public zone access the private zone via a third zone, the DMZ. The DMZ, or demilitarized zone, is an intermediary zone that provides a level of isolation and additional security between the public and private zones, further protecting the bulk of the application contained in the private zone.

The purpose of this three-zone model is to keep the “wild raw internet” away from the sensitive parts of your application. Two isolated zones, the public zone and DMZ, provide a layer of protection between the public internet and the bulk of the back-end services.

The zones are isolated from each other by using separate, private, networking segments that have specific network and application-level security firewalls connecting them. While traffic generally flows freely within the public zone on the front end, it is restricted in the private zone on the back end, so that only services that are designed to talk to one another can communicate. No unnecessary communication between back-end services is allowed. All of these restrictions are designed to limit the blast radius, or impact area of an attack. If part of your system is compromised, these protections will make it difficult for the attacker to delve deeper into your application. Your sensitive data, stored deep in the bowels of the private zone, are separated from any bad actors by many layers of protection.

Standard cloud security controls

In the cloud, Amazon Web Services (AWS), Microsoft Azure, and Google Cloud all offer standard security mechanisms that help in the construction and management of these zones. For example, AWS provides specific tools and services that assist in creating these security zones and provide the isolation required between them:

• Amazon VPCs. VPCs, or virtual private clouds, provide isolated IP address ranges and routing rules. Each security zone can be created as a separate VPC. Then, specific routing rules are created to control the flow of traffic among the VPCs. By making each zone a separate VPC, you can easily create the zones and keep them isolated. This model keeps the traffic inside each zone local to that zone. Traffic destined to move from a service in one zone to a service in another zone must go through natural “traffic opt-in” points that limit the type of traffic that can flow. These network-level firewalls are the first line of defense in keeping your security zones isolated.
• Security Groups. Security groups provide server-level firewalls that control the traffic that flows into individual instances. They are typically attached to each server instance you allocate, along with other cloud component instances, such as databases. Security groups can be used to prevent unauthorized access to any given component. For example, a security group could make sure that traffic arriving at a transition service’s server must have originated from a specific set of front-end services, and could not have originated from any other server on the internet. Security groups provide solid, server-level security, but do require diligence to make sure they are configured to allow only the appropriate traffic to specific instances. As such, they should be used with VPCs, not in place of them, to create your isolation zones.
• Network ACLs. These provide network-level access control. They prevent unwanted traffic from flowing anywhere within a given VPC among individual servers and services. Network ACLs are stateless, meaning they manage low-level IP traffic and not specific point-to-point communications channels. As such, they provide a broad shield to your security zones, while security groups provide specific, detailed protection. For example, network ACLs could be used to prevent anyone from attempting to log in directly to a back-end service by disallowing all SSH traffic in the zone.

Each security zone typically sets up different security rules. In the public zone, for example, it may be reasonable to allow services inside this less secure zone to communicate in a very open manner. However, in the private zone, communications between services may be severely limited. Of course, depending on your application, the specific security requirements you use for each zone may vary widely.

However you set up your security zones, they provide a solid best practice for improving the security of your application, and for keeping your data safe and secure. Security zones should be considered an important tool in your arsenal for maintaining application security.