TL;DR

Many organisations are migrating workloads to Azure Landing Zones (LZs), pre-configured building blocks in Microsoft Azure enabling you to build secure and scalable cloud environments.

Even though the core principles of this kind of setup might sound simple enough, many (like me) find that actually designing the flow of traffic within LZs can quickly become a complex exercise.

This blog post will try to help guide this process, by exploring five areas that have proven valuable for LZs owners setting up traffic paths and flows in a secure manner. These include:

• Virtual Networks (vNets)
• Network Security Groups (NSGs)
• Web Application Firewall (WAF)
• Private Endpoints (PEs)
• Virtual Network Integration (vNet Integration)

Background

A key principle in the LZs model is that each development team will have ownership over their own LZs.

Microsoft’s Cloud Adoption Framework (CAF) helps guide architects in creating the high-level designs while the Well Architected Framework is a more detailed guide to migrate workloads, with some really great design principles. None of them however, are detailed enough to help LZs owners set up traffic paths and flows in a secure manner.

The thing with Azure is that it is “working by design” meaning there are standard rulesets and configuration in place to “just make things work”. This helps everyone get workloads working fast. But securing them requires work and knowledge.

In the frameworks, Microsoft advises owners to use private endpoints where possible, use Azure Network Security Groups (NSGs) everywhere, and set up a Web Application Firewall and control the flow of traffic with route tables. As guiding principles this sounds easy enough, however when actually trying to design the flow of traffic within a LZ it quickly becomes complex.

Below you can find what I have observed to be the five most valuable recommendations for a more secure setup for LZs owners.

A secure foundation for designing traffic paths within Landing Zones

Virtual Networks (vNets)

A virtual network in Azure is really just a placeholder to reserve IP space. To actually deploy network interfaces and have any traffic you need to provision subnets. All traffic generation in a vNet must originate from a subnet. Filtering and routing all happens within the subnet. vNets are essentially a collection of subnets that can share peerings to other vNets and share DNS configuration which is both configured on the vNet level.

Network Security Groups (NSGs)

The current standard is an NSG surrounding each subnet. This is the best practice and each subnet should always have its own unique NSG. On the surface NSGs may look simple, a classic access list one might think. But that is not the case. The NSGs are a L3/L4 filter, but rather than filtering only traffic in and out of a subnet, it will filter all traffic within the subnet as well. Imagine a NSG around each network interface within the subnet.

This means that for traffic between two hosts within a single subnet there is a need for both an outbound and an inbound rule to allow the traffic flow.

By default, Microsoft has set up some default rules.

These rules will allow all traffic on all ports within the vNet. This is great for just making things work, but it breaks all rules of micro-segmentation and Zero-Trust.

The Zero-Trust framework, principle of least privilege and micro-segmentation all state that access should only be granted where needed. All openings in NSGs should be explicit and for a reason. The best practice for NSGs is to negate the default rules with a deny any-any rule both outbound and inbound with a priority as high as possible, all openings should be intentional.

This will create some challenges when it comes to native functionality of load-balancers and such, which relies upon these rules. But there are still ways to make it work without compromising security. The important thing to understand is that Azure Load Balancers do Network Address Translation (NAT) before the traffic is filtered by the NSG. So inbound rules where traffic passes through a load balancer must have all members of the backend-pool as allowed destinations.

In the illustration above the Client NSG would need an
Outbound Rule:

While the Application NSG would need an
Inbound rule:

In addition, the Application NSG would also need to allow inbound health-probes from the load-balancer. Those probes will originate from 168.63.129.16 with the port chosen for the health-probe. Resulting in the image below:

Web Application Firewall (WAF)

Azure Application Gateway WAF should be added in front of applications. The WAF decrypts and inspect user traffic, logs suspicious activity, and block attempts to compromise the applications.

Most companies require a WAF solution in place at least in front of their public facing web-applications, but more and more also use it for internal use as well. A lot of regulatory standards also require a WAF solution. The WAF will Source-NAT the traffic so that the applications can restrict network access to their endpoints.

This post will not dive deeper into the WAF technology, but suffice to say it is a field of study on its own and there are a lot of different products available in addition to Azure WAF.

Private Endpoints (PEs)

Microsoft PaaS services such as Azure Web Apps, Azure SQL DB, and Storage accounts are by default public facing towards internet. To lock it down to your local network with a private IP you need to configure a private endpoint for the service. Note that private endpoints can only ever receive traffic. There is no way to generate outbound traffic from a private endpoint.

As an example, consider a distributed application migrated to be hosted on two Azure Web Application Services. This gives the App Services a private listening IP where the application can be reached over the local network. Public access on the App Services directly can now be disabled and the only way to reach the application should be through the private endpoints.

Note that for propagated routing and NSGs to be enabled for private endpoints it must be enforced on the subnet.

Microsoft’s Well Architected Framework states that all PaaS services should use private endpoints. It does however not state how those private endpoints should be placed in regards to subnet. Best practice is to keep the applications as segmented as possible, but since each private endpoint holds a unique private IP, it’s possible to limit access  through the NSGs. It is common to group together at least web-applications within the same level on the same subnet. This way, all front-end facing applications can share a subnet, but not share it with backend applications or solutions such as storage or database.

Virtual Network Integration (vNet Integration)

Most applications require connectivity towards databases, storage accounts etc. To facilitate this, Microsoft has added the vNet Integration feature to allow PaaS products to make outbound requests on the local virtual network.

The vNet integration functions by choosing a random IP from the integration subnet to source its requests from. This is great for remediating source-NAT port-exhaustion. But it also generates a security challenge. This means that for all apps which share an integration subnet, there is no way for any NSG, firewall, or other network device to discern which app is generating the request. For enterprises with strict network access rules, opening up critical databases or archive solutions to all applications in a LZ will not be allowed. In such cases it is advisable to designate one integration subnet per application to be able to filter and control traffic from each app.

Concluding remarks

Together, these actions will create a valuable basis for designing traffic paths within a Landing Zone.

As Landing Zones often have integrations and dependencies outside its own LZ, this is a rich topic I’d like to come back to. Next up in this blog-series, I will dig into related topics such as securing this traffic.