Implement network segmentation patterns on Azure
Create segmentation in your network footprint by defining perimeters. Main reasons for segmentation are:
- The ability to group related assets that are a part of (or support) workload operations.
- Isolation of resources.
- Governance policies set by the organization.
Network controls can secure interactions between perimeters. This approach can strengthen the security posture and contain risks in a breach because the controls can detect, contain, and stop attackers from gaining access to entire workload.
How does the organization implement network segmentation?
This article highlights some Azure networking features that create segments and restrict access to individual services.
Align your network segmentation strategy with the enterprise segmentation model. This will reduce confusion and challenges with different technical teams (networking, identity, applications, and so on). Each team should not develop their own segmentation and delegation models that don’t align with each other.
- Create software-defined perimeters in your networking footprint and secure communication paths between them.
- Azure Virtual Networks (VNets) are created in private address spaces. By default no traffic allowed by default between any two VNets. Open paths only when it's really needed.
- Use Network Security Groups (NSG) to secure communication between resources within a VNet.
- Use Application Security Groups (ASGs) to define traffic rules for the underlying VMs that run the workload.
- Use Azure Firewall to filter traffic flowing between cloud resources, the internet, and on-premise.
- Place resources in a single VNet, if you don't need to operate in multiple regions.
- If you need to be in multiple regions, have multiple VNets that are connected through peering.
- For advanced configurations, use a hub-spoke topology. A VNet is designated as a hub in a given region for all the other VNets as spokes in that region.
What is segmentation?
You can create software-defined perimeters in your networking footprint by using the various Azure services and features. When a workload (or parts of a given workload) is placed into separate segments, you can control traffic from/to those segments to secure communication paths. If a segment is compromised, you will be able to better contain the impact and prevent it from laterally spreading through the rest of your network. This strategy aligns with the key principle of Zero Trust model published by Microsoft that aims to bring world class security thinking to your organization.
Azure features for segmentation
When you operate on Azure, you have many segmentation options.
Subscription: A high-level construct, which provides platform powered separation between entities. It's intended to carve out boundaries between large organizations within a company and communication between resources in different subscriptions needs to be explicitly provisioned.
Virtual Network (VNets): Created within a subscription in private address spaces. They provide network level containment of resources with no traffic allowed by default between any two virtual networks. Like subscriptions, any communication between virtual networks needs to be explicitly provisioned.
Network Security Groups (NSG): An access control mechanisms for controlling traffic between resources within a virtual network and also with external networks, such as the internet, other virtual networks. NSGs can take your segmentation strategy to a granular level by creating perimeters for a subnet, a VM, or a group of VMs. For information about possible operations with subnets in Azure, see Subnets (Azure Virtual Networks).
Application Security Groups (ASGs): Similar to NSGs but are referenced with an application context. It allows you to group a set of VMs under an application tag and define traffic rules that are then applied to each of the underlying VMs.
Azure Firewall: A cloud native stateful Firewall as a service, which can be deployed in your VNet or in Azure Virtual WAN hub deployments for filtering traffic flowing between cloud resources, the internet, and on-premise. You create rules or policies (using Azure Firewall or Azure Firewall Manager) specifying allow/deny traffic using layer 3 to layer 7 controls. You can also filter traffic going to the internet using both Azure Firewall and third parties by directing some or all traffic through third-party security providers for advanced filtering & user protection.
Here are some common patterns for segmenting a workload in Azure from a networking perspective. Each pattern provides a different type of isolation and connectivity. Choose a pattern based on your organization's needs.
Pattern 1: Single VNet
All the components of the workload reside in a single VNet. This pattern is appropriate you are operating in a single region because a VNet cannot span multiple regions.
Common ways for securing segments, such as subnets or application groups, are by using NSGs and ASGs. You can also use a Network Virtualized Appliance (NVAs) from Azure Marketplace or Azure Firewall to enforce and secure this segmentation.
In this image, Subnet1 has the database workload. Subnet2 has the web workloads. You can configure NSGs that allow Subnet1 to only communicate with Subnet2 and Subnet2 can only communicate with the internet.
Consider a use case where you have multiple workloads that are placed in separate subnets. You can place controls that will allow one workload to communicate to the backend of another workload.
Pattern 2: Multiple VNets that communicate through with peering
The resources are spread or replicated in multiple VNets. The VNets can communicate through peering. This pattern is appropriate when you need to group applications into separate VNets. Or, you need multiple Azure regions. One benefit is the built-in segmentation because you have to explicitly peer one VNet to another. Virtual network peering is not transitive. You can further segment within a VNet by using NSGs and ASGs as shown in pattern 1.
Pattern 3: Multiple VNets in a hub and spoke model
A VNet is designated as a hub in a given region for all the other VNets as spokes in that region. The hub and its spokes are connected through peering. All traffic passes through the hub that can act as a gateway to other hubs in different regions. In this pattern, the security controls are set up at the hubs so that they get to segment and govern the traffic in between other VNets in a scalable way. One benefit of this pattern is, as your network topology grows, the security posture overhead does not grow (except when you expand to new regions).
The recommended native option is Azure Firewall. This option works across both VNets and subscriptions to govern traffic flows using layer 3 to layer 7 controls. You can define your communication rules and apply them consistently. Here are some examples:
- VNet 1 cannot communicate with VNet 2, but it can communicate VNet 3.
- VNet 1 cannot access public internet except for *.github.com.
With Azure Firewall Manager preview, you can centrally manage policies across multiple Azure Firewalls and enable DevOps teams to further customize local policies.
Here are some resources that illustrate provisioning of resources in a hub and spoke topology:
The design considerations are described in Hub-spoke network topology in Azure.
|Considerations||Pattern 1||Pattern 2||Pattern 3|
|Connectivity/routing: how each segment communicates to each other||System routing provides default connectivity to any workload in any subnet.||Same as a pattern 1.||No default connectivity between spoke networks. A layer 3 router, such as the Azure Firewall, in the hub is required to enable connectivity.|
|Network level traffic filtering||Traffic is allowed by default. Use NSG, ASG to filter traffic.||Same as a pattern 1.||Traffic between spoke virtual networks is denied by default. Open selected paths to allow traffic through Azure Firewall configuration.|
|Centralized logging||NSG, ASG logs for the virtual network.||Aggregate NSG, ASG logs across all virtual networks.||Azure Firewall logs all accepted/denied traffic sent through the hub. View the logs in Azure Monitor.|
|Unintended open public endpoints||DevOps can accidentally open a public endpoint through incorrect NSG, ASG rules.||Same as a pattern 1.||Accidentally opened public endpoint in a spoke will not enable access because the return packet will get dropped through stateful firewall (asymmetric routing).|
|Application level protection||NSG or ASG provides network layer support only.||Same as a pattern 1.||Azure Firewall supports FQDN filtering for HTTP/S and MSSQL for outbound traffic and across virtual networks.|
For information about setting up peering, see Virtual network peering.
For best practices about using Azure Firewall in various configurations, see Azure Firewall Architecture Guide.
For information about different access policies and control flow within a VNet, see Azure Virtual Network Subnet
Back to the main article: Network security