skip to Main Content

How to Implement Network Segmentation at Scale in Azure

Azure Network Segmentation Strategies

Segmentation in the public cloud usually starts with network security groups (NSGs). In an Azure virtual network, you can use NSGs to filter network traffic to and from Azure resources. Network firewalls and web application firewalls are typically deployed at the edge networks, filtering traffic between trusted and untrusted zones. The Zero Trust approach extends this model by applying segmentation policies between internal networks:

  • Inside the VNET (VMs talking to each other in the same VNET) 
  • VNET-VNET communication (within a single subscription or across multiple subscriptions)
  • VNET to Azure Services communication 

There are several challenges with implementing micro-segmentation in Azure: 

  • Appliance-based firewalls can’t keep up: Workloads are dynamic, and IP addresses change all the time. This dynamic nature of the cloud makes it difficult to build network segmentation policies that stay relevant as new workloads are deployed and scaled.
  • Azure Application Security Groups (ASGs) are limited to a single VNET: Azure application security groups (ASGs) simplify the configuration and management of NSGs, by configuring network security as an extension of an application’s structure. Using ASGs you can apply network segmentation without manual maintenance of workload IP addresses. ASGs are great at segmenting the workloads within the same VNET and a single subscription. They fall short when it comes to multi-subscription or multi-VNET segmentation. 

This blog looks at how Valtix can apply cloud-native segmentation in Azure at scale. 

What are Azure Application Security Groups (ASGs)

Let’s quickly review how Azure application security groups (ASGs) allow you to secure your application without manual maintenance of explicit IP addresses. 

Let’s say that you are building a multi-tiered payroll application in the US East region. You need to have a portal for the users to log in and enter their information and view their paystubs. The application logic layer also needs to interact with the web tier and the backend services such as Azure Cosmos DB. 

You can apply a network security group (NSG) on a subnet level and associate your web frontend Azure VMs with a Web (web application tier ASG), and your application VM with a Logic (business logic application tier ASG)

ASG-based segmentation in a single Azure VNET

You can then apply security rules to ASGs instead of each of the VMs individually. For example, the below rule allows HTTP traffic from the Internet (TCP port 80) to VM1 and VM2 in the web application tier, by specifying WebASG as the destination, instead of creating a separate rule for each VM.

Priority Source Source Ports Destination Dest Ports  Protocol Access
100 Internet     * Web (ASG) 80, 443 TCP ALLOW

Example ASG Policy

The benefit of this approach is that the security policies don’t get stale as your workload scales out or in. For example, the NSG in this case doesn’t need to be updated when the auto-scaling set adds web service VMs. They are good to go as long as they are tagged properly with ASG = Web.    

Why Azure ASGs are not enough?

Let’s say now that your payroll application is getting popular, and you’re getting new requirements for a real-time dashboard to display trends and analytics around time-off requests and extra time pay. For these real-time capabilities, you need to connect to other subscriptions and VNETs hosting the SAP VNET and also Azure HDInsight to do real-time data processing.

ASG-based segmentation across multiple Azure VNET and subscriptions 

This is the sample policy that you need to build:

Priority Source Source Ports Destination Dest Port  Protocol Access
100 Payroll VNET Logic (ASG)     * ERP VNET  SAP (ASG) 1433 TCP ALLOW

Desired ASG-Based policy across multiple VNETs and subscriptions 

You soon realize that ASG-based policies are not extensible across VNETs and subscriptions. So how can you extend this dynamic network segmentation policy across VNETs, subscriptions, and regions? The short answer is to use Valtix

What is Valtix?

Valtix is a cloud-native platform that integrates with your Azure subscriptions and automatically discovers cloud assets including ASG tags. This allows you to build security policies leveraging cloud context that can be extended across subscriptions, VNETs, and even different clouds. 

Here’s the kind of Cloud context that can be used in a policy: 

  • VNet ID
  • Application Security Group (ASG)
  • User Defined Tags 
  • Resource Group ID

 

Priority Source Source Ports Destination Dest Port  Protocol Access
10 Payroll VNET Logic (ASG)     * ERP VNET  SAP (ASG) * TCP ALLOW

Security Policy in the Valtix controller

The Valtix SaaS controller automatically discovers your ASG tags by integrating with your Azure subscription. This provides real-time discovery so as new workloads come online with this ASG tag, Valtix can find them and populate the policy automatically. Here is an example of an address group defined in the Valtix controller leveraging (ASG) = Payroll. Valtix has discovered the IP address (10.150.20.8) associated with this ASG.

The Valtix controller also supports CI/CD automation using Terraform. So everything here can be automated using Terraform and added to your existing pipeline.

Valtix policy configuration in Terraform template

What’s Next 

Valtix fast-tracks your Zero Trust journey by providing advanced network security that is cloud-native. With Valtix you can extend your Azure application security groups across multiple VNETs and subscriptions. You can deploy comprehensive security to cover multiple use cases including segmenting: 

  • Perimeter security to protect ingress and egress traffic 
  • Inside the VNET 
  • VNET-VNET 
  • VNET to Azure Services communication 

Get hands-on and try Valtix Free Tier in your own environment. Let us know what you think.

Latest Posts

Can Data Center Leaders Reverse Their Irrelevance In the Cloud Era?

Back To Top