Building Cloud-Native Applications Using Isolation Zones

Cloud-native architectures are perfect for creating and operating modern, innovative applications. Cloud-native applications provide many advantages both to consumers of the applications and to those building and managing them.

But bad actors abound, and securely maintaining your cloud-native application is no easy task. There are many things you can—and should—do to keep your application secure.

One technique to improve the security of your cloud-native application that is often overlooked is the use of isolation zones.

What are isolation zones? Isolation zones are a process of separating your application into multiple security regions that are, as much as possible, isolated from each other.

Using Isolation Zones

An application is stored in multiple zones. Each zone performs some necessary part of the overall application processing. The outer zone is the closest to customers—and the public internet—and is considered the most insecure. Only those actions that must occur in this exposed area occur here. When an application needs to perform more secure operations, it calls back into successively more secure zones. The innermost zone is the most secure and is where the most sensitive processing and sensitive data is stored. Each zone can only talk to the zones immediately adjacent to it and cannot reach into zones deeper within the application without going through services in each intervening layer.

Sponsorships Available

Sponsorships Available

Sponsorships Available

The technique of using isolation zones works best for cloud-native applications that are based on services and microservices architectures. This is because cloud providers offer easy-to-set-up tools (such as VPCs) to create and manage isolation zones—and because services-based applications can be divided into multiple zones much more easily than monoliths can. Hence, using isolation zones is particularly useful for cloud-native applications.

Defining Your Zones

There isn’t one model for defining your zones; there are many ways you can architect your zones based on your application needs. But if you are just starting out building isolation zones for your applications, I recommend starting with three basic zones:

1. Public Zone. This is the outermost zone—the zone connected directly to the public internet. In this zone, you place services and components responsible for validating that traffic arriving from the public internet. This includes basic traffic filtering, BOT blockers, firewalls, etc. But this zone also has services responsible for validating a user’s access to the site, including authorization, authentication and basic permission management. Services in this zone can talk directly to the public internet and they can talk to services in the next zone inwards, namely the DMZ.
2. Demilitarized Zone (DMZ). This is the zone that connects the public zone to the private zone. It provides an isolation buffer between the services in the relatively insecure public zone and the public internet and the services in the very safe private zone. This zone vets messages from the public zone and ensures they go only to the proper location within the private zone. This zone is the traffic cop. It keeps all communications between public and private safe and secure.
3. Private Zone. This zone is where most of your deeper application processing and most of your application’s data is stored. It’s the most secure zone and is the furthest away from the public internet. Services in this zone can typically freely interact with each other as needed but can only talk “outwards” to services in the DMZ. They cannot communicate to or receive messages from any services in the public zone or the public internet without being vetted through the DMZ.

These are only the most basic bare-bones zones. Depending on your application, you may have other specific security needs that require a different zone structure. For example, the following application requirements could generate additional needs:

• Financial transaction management. If your application deals with credit card payments and processes the credit cards directly itself (versus using a service such as Stripe), you typically have to deal with additional security requirements defined by systems such as PCI. These regulations impose strict security requirements on the services that use credit cards and the data stores that store credit card information. These requirements often extend to services that interact directly with these services. To meet this higher security requirement, impacted systems are typically contained in a separate isolation zone to separate them from the rest of the application. This limits the scope of services impacted by PCI but also improves the security of those services within the zone.
• HIPAA. If you deal with personal medical information, you have many requirements on how and where you store this data, as required by HIPAA. Services that deal with this data may be easier to manage and properly secure if they are in a separate zone.
• Other Highly Sensitive information. If you deal with highly sensitive data—whether this is governmental secrets or sensitive employee data—keeping the data secure is critical to your business. The services that use and store this data should be in separate, highly sensitive zones. This will ease your security burden and provide a higher level of security overall.

Keeping applications and data safe is critically important to virtually all cloud-native applications and is becoming increasingly important and complex. Using security zones is just one tool of many that can help you isolate components of your system, which will improve the overall security of your application.