Isolation or security zones protect your applications and data from intruders and can help limit the impact of a vulnerability. […]
For a successful business, it is crucial that your applications are safe and secure. Whether you’re using cloud-native application architectures or on–premises systems – or anything in between – splitting your infrastructure into security zones is considered a best practice. These zones provide a protective isolation that protects your applications and their data from outside attackers. An intrusion into an area thus only has an impact on the resources in that one area.
When used correctly, this zone-based isolation process can turn a security malfunction that could otherwise have a massive impact on the integrity of your application into a much smaller problem, possibly even an insignificant malfunction with minimal impact.
Understanding Security zones
Although there are many different ways to set up security zones, but a common model is the use of three zones. The three zones provide a separation between the public Internet (public zone) and your internal services and data storage (private zone) by inserting an isolation layer (DMZ) between the two. Figure 1 shows how these areas work together.
Users interact with your application over the public Internet by accessing services in the public zone. The public zone is connected to the Internet and therefore freely accessible. The services in this zone are directly exposed to the Internet and are directly accessible via the Internet. The Services run on servers that are protected by various firewalls, but otherwise receive traffic directly from users from the external Internet.
These publicly accessible services do as little work as possible, but one of their most important tasks is to regulate and verify the data received from the external Internet to ensure that it is valid and adequate. These services should filter denial-of-service (DoS) attacks, intrusion by attackers, and invalid input from end users.
The bulk of the application is in the private zone. This zone stores the application data and the services that access and edit the data, as well as most of the backend of your application. As much of the application as possible should be located here. This zone is the farthest from the public Internet. There are no publicly accessible servers in this zone. The zone is isolated from the public Internet as much as possible.
To ensure the security of the private zone, no one can directly access the services in this zone. Also, services in the public zone of the application cannot access services in the private zone. Instead, the services in the public zone access the private zone through a third zone, the DMZ. The DMZ or Demilitarized Zone (demilitarized zone) is an intermediate zone that provides a certain degree of isolation and additional security between the public and private zones and further protects the bulk of the application contained in the private zone.
The purpose of this three-zone model is to keep the “uncontrolled Internet“ away from the sensitive parts of your application. Two isolated zones, the public zone and the DMZ, provide a layer of protection between the public Internet and the bulk of backend services.
The zones are isolated from each other by using separate, private network segments that are connected to each other via special security firewalls at the network and application level. While the data traffic in the public zone at the front-end can usually flow freely, it is restricted in the private zone at the back-end, so that only the services intended for it can communicate with each other. Unnecessary communication between backend services is not allowed. All these restrictions are designed to limit the radius of action of an attack. If a part of your system is compromised, these protections make it difficult for the attacker to penetrate deeper into your application. Your sensitive data, stored deep in the innards of the private zone, is separated from the attackers by several layers of protection.
Standard Cloud security
In the cloud, Amazon Web Services (AWS), Microsoft Azure, and Google Cloud provide standard security mechanisms to help create and manage these zones. For example, AWS provides special tools and services that help create these security zones and provide the necessary isolation 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 between the VPCs. By making each zone a separate VPC, you can easily create the zones and keep them isolated. With this model, the traffic within each zone is limited to the respective zone. The traffic that should flow from a service in one zone to a service in another zone must pass through natural opt-in points that limit the type of traffic flowing. These network-level firewalls are the first line of defense to keep 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 assign, along with other instances of cloud components, such as databases. Security groups can be used to prevent unauthorized access to a particular component. For example, a security group can ensure that the traffic arriving on the server of a transition service must come from a certain group of front-end services and cannot come from another server on the Internet. Security groups provide solid security at the server level, but require careful configuration to ensure that they only allow the appropriate traffic to specific instances. Therefore, they should be used together with VPCs, and not instead of VPCs, to create their isolation zones.
- Network ACLs.
These provide access control at the network level. They prevent unwanted traffic within a specific VPC from flowing between individual servers and services. Network ACLs are stateless, i.e. they manage IP traffic at the lowest level, and not specific point-to-point communication channels. As such, they provide broad protection for your security zones, while security groups provide specific, detailed protection. For example, network ACLs can prevent someone from trying to log in directly to a backend service by blocking all SSH traffic in the zone.
For each security zone, as a rule, different security rules are established. In the public zone, for example, it may be useful to allow the services within this less secure zone to communicate very openly. In the private zone, on the other hand, communication between services can be severely limited. Of course, the specific security requirements you use for each zone can vary greatly depending on the application.
However you set up your security zones, they represent a solid best practice to improve the security of your application and keep your data safe. Security zones should be considered as an important tool for maintaining application security.
*Lee Atchison is a recognized thought leader in cloud computing and application modernization. With more than three decades of experience in product development, architecture, scaling and modernization, Lee has worked at Amazon, Amazon Web Services (AWS), New Relic and other companies for modern applications.