Controlling Data Egress in Azure

[Guest CraigDuBose]

Summary: Regulated companies impose stringent requirements on data governance to prevent data exfiltration. As a Cloud Architect, ensuring the safe and efficient exit of data from our network to external destinations is paramount. This document aims to provide a comprehensive guide to the strategies, best practices, and tools we employ at various customers to maintain robust security measures.

 

 

 

What Azure services allow data egress?

 

• Virtual Network subnets or VMs without UDR or BGP Control - traffic can leave the default outbound access IP which is not controllable or managed by the customer.
  
  • Private VNETs will be available with secure by default enabled scheduled 2025 and will provide a means to disable this unmanaged Public egress pattern. - Azure Private Subnet
    
  • User Defined Route (UDR) - Routes added to UDRs can inject routes to VMs and services deployed to a subnet.
    
    • A UDR can have a route that directs traffic directly to the internet, but this traffic would go out as mentioned above via a customer unmanaged IP address.
      
    • If the Subnet has a NAT Gateway associated to it and has a route targeting traffic to next hop internet, it should reach the public internet via the NAT Gateway's associated IP addresses.
      
    • If the Subnet has a route targeting traffic to next hop Azure Firewall or 3rd party NVA, the traffic will reach the internet via that devices route table or public IP address.
      

  [*]NAT Gateway - NAT Gateway plays a role in allowing a subnet to reach the internet from a specific IP address or prefix. This allows data to leave and reply to requests BUT does not allow an Ingress point for data.

  • A scenario here would be: I have an Azure VM that needs to reach out to our partner who whitelists IP addresses that can communicate with them. A NAT Gateway would allow that known public IP address to be provided to the partner without allowing unsecure access to your virtual machines. More information can be found here: NAT Gateway
    

  [*]VNET Gateway for Express Route or VPN (VNG) - Data can only leave Virtual Network Gateways if it is going through a Express Route or VPN (S2S or P2S). If traffic destined for the public internet is directed to the VNG, the traffic will drop. If you need traffic from subnets to leave a known IP address on your network, please leverage NAT Gateway. If Traffic is directed via a BGP or UDR entry to an on-prem IP address, the traffic can pass through the VNET Gateway over the secure connection to the on-prem IP address for egress.

  [*]Public IP Addresses - If an Azure VM or PaaS service has a public IP address, traffic will egress from that known published Public IP address.

  • For example, if a 3rd party network solution (Cisco or Palo Alto for example) is deployed on a VM in Azure with a public IP address associated to it, traffic on the internet would show that data's source would be the public IP address assigned to the VM. Public IP Egress for VMs
    
  • External Load Balancer (ELB) - For example, if a 3rd party network solution (Cisco or Palo Alto for example) is deployed on a VM in Azure without a public IP address associated to it, but has a Public Standard Load Balancer attached, the traffic on the internet would show that data's source would be the public IP address assigned to the ELB. Azure VM Outbound Connectivity Methods
    
  • For PaaS Services with Public IP addresses, it can reach the internet through its public IP Address. If the PaaS Service supports VNET integration, that traffic can be redirected to the appropriate network services to control/govern that data as needed. If VNET integration is enabled and the subnet connected to the PaaS service has a NAT Gateway or a UDR directing the applicable traffic, the traffic would come from that known IP address instead. Azure VNET Integration
    

  [*]Public IP Prefix - Public IP Prefixes allow a group of IP addresses to be used for data egress on services such as Virtual Machines, Standard Load Balancers, Azure Firewall, and VPN Gateway. The benefit of this service is to allow you to expand past the standard network limits for a single public IP address such as SNAT (Source NAT). Azure Public IP Prefix

  [*]Azure Firewall (AzFW) - Azure Firewall is a scalable Cloud-Native Firewall. AzFW can replace or supplement 3rd party network solutions in a number of secure network designs, but focusing on egress, traffic directed to the Azure Firewall can egress to the internet via a NAT Gateway or an associated public IP address. Azure Firewall Public IP Address

  [*]Azure Firewall has a huge number of security benefits which can be found: Azure Firewall Version Comparison

 

Now that we discussed what can egress, how can we monitor/secure it? What does this look like in practice?

 

• Azure Network Security Group (NSG) - As mentioned in various documents, micro segmentation is a key component of ensuring zero trust and reducing attack surfaces for network attacks. When creating NSG rules - similar to ACLs (Access Control Lists) in other network solutions, ensure only approved traffic is allowed. NSGs
  
  • Example: If I have a web server running on a windows VM that doesn't require egress, ensure the NSG rules specify:
    
  • Inbound:
    
    • Allow port 443 for https from its allowed sources at priority 100
      
    • RDP for management/access at priority 101
      
    • Implicit DENY for all inbound traffic at rule priority 4000.
      
    • Default rules at 65000, 65001, and 65500 should be ignored.
      

    [*] Outbound:

    • Allow outbound communication to authentication servers at priority 100
      
    • Allow outbound communication to DNS servers at priority 101
      
    • Allow outbound communication to management applications at priority 101
      
    • Implicit DENY for all outbound traffic at rule priority 4000.
      
    • Default rules at 65000, 65001, and 65500 should be ignored.
      

• NSGs have default rules that allow certain traffic BEFORE the implicit deny. If you are advertising addresses through a Virtual Network Gateway from a Site-to-Site VPN or BGP configuration, the on-prem communication may be allowed as part of the 'VNET communication' default rule since it is a private address that announced to your Virtual Networks.
  
• Flow Logs:
  
  • Only Option Until April 2024 - NSG Flow Logs - NSG Flow logs can help monitor what traffic is being allowed to reach the various sources including the public internet. This information can be sent to a SIEM solutions for central review of all traffic from Azure.
    
  • VNET Flow logs was released April 2024, can simplify the capturing of flow logs and be deployed per VNET instead of per subnet. - VNET Flow Logs
    

  [*]Azure UDR - User Defined Routes can control what routes are published to subnets in Azure and can control if routes from on-prem are published to Azure. Routes such as Communication to IP addresses, IP ranges, or Azure Services can be manipulated to direct traffic. For example, if an environment is using an Azure Firewall for Azure Native traffic, but all other traffic firewall should be going to a particular 3rd party solution to leave the environment:

  • Subnets will have a UDR that directs the applicable Service Tag will say next hop = Azure Firewall.
    

  [*]Azure Service Tags - A Service Tag is a Microsoft Managed logical grouping of public IP addresses in the Azure Backbone to provide access to services with or without region association. Examples can be found: Service Tags

  [*]Azure Policy

  • NSGs should be associated with all subnets
    
  • Flow Logs should be deployed to capture all data on networks in Azure.
    
    • Per Subnets - Flow logs should be configured for every network security group
      
    • Per Virtual Networks - Audit flow logs configuration for every virtual network
      

 

 

 

What can govern your Azure Data Egress requests?

 

• Azure Firewall
  
  • Deploy Route Table to control traffic. Azure Firewall UDR Support
    
  • Network Rules on Azure Firewall to control traffic
    

  [*]3rd party NVAs (Palo, Cisco, Juniper, etc)

  • Deploy Route Table to control traffic. Azure Firewall UDR Support
    
  • Network Rules on NVAs to control traffic
    

  [*]Azure NSGs

  • Deployed per subnet as mentioned above.
    

 

 

 

 

 

In conclusion, the secure management of egress traffic is a critical component of our overall security posture. By adhering to the guidelines and principles outlined in this document, we fortify our defenses against potential threats and ensure the integrity of our data as it traverses beyond the confines of our internal network. Thank you for your commitment to upholding these standards and contributing to our collective security efforts.

 

Continue reading...