Azure network segmentation patterns

3 min read

Over the past 7 years, I have mostly been working with organisations to design and build-out their cloud landing zones. One of the main patterns that needs resolving is how to build out the network to meet the organisations security and architecture requirements. There isn't a silver bullet, and every organisation is different. However, there have been 3 key patterns that I end up recommending.

Bear in mind, you can use one, or a mix of each of these depending on your use-case. Remember, networking is only one part of the puzzle, and needs to sit within a larger landing zone framework. I don't cover that here (might end up with a separate post, you never know!), but you should take a look at Enterprise Scale Landing Zones.

I'll cover three patterns here. These are:

  • Dedicated VNet
  • Tiered VNet using subnets
  • Micro-segmentation per application

Dedicated VNets

This pattern is great to use when hosting services within a DMZ, untrusted zone or micro-service environment. Here we simply create a virtual network per application (so Microservice1), and tier within different application tiers using subnets (see my next pattern). Using this model, if the application was to become compromised, lateral movement would be isolated to the application itself, rather than traversing the rest of your environment.

Where communicating between different applications, modern patterns such as integration layers, APIs and ETL services moves the security enforcement up the stack, simplifying the architecture.

Tiered VNets with subnets

This pattern can be used as part of the previous one, or on it's own. This one usually comes into play when you are hosting IaaS type applications, mostly when you 'lift and shift'. With this model, you would typically have a virtual network per environment (e.g., Production, Development etc.) and then carve it up into separate tiers using subnets. Examples here would include Web, App and Data tiers.

Locking down communication between the tiers would be done using Network Security Groups, that only allow traffic from the allowed tiers to traverse (e.g., Web can only talk to app, and App can only talk to Data).

The downside to this model is multiple applications may share the same subnet... and as such, once one is breached lateral movement between the applications is possible.

Micro-segmentation per application

This is the most complicated of the three, and requires some thought and planning as you move and deploy applications into the architecture. As with most things cloud, don't try doing this manually. Tooling like Terraform and Azure Resource Manager will make this much smoother.

In this model, we would have a single virtual network as your security zone (production for example). Then, for each application and it's tier you deploy, has it's own subnet. So for a typical application, you may have Application1-WebTier, Application1-DatabaseTier and duplicated for each application.

IP management becomes critical here, so make sure you only allocate the required IPs to the subnet.

Now, with this model, you can apply an NSG to each subnet, that only allows the relevant ports through based on requirements. So the Application1-DatabaseTier will only allow virtual machines from Application1-WebTier in on TCP Port 1433. You would then block traffic from the rest of the VNet.

Quick tip, use Application Security Groups to simplify your rule base!

As with anything in the world of cloud, treat these as patterns.. there is nothing to say one will work for every use case. Governance is key to keeping your estate secure and aligned with your requirements. In a future post, I will provide the technical implementations for each pattern listed above. There might even be a video en-route!