Secure Azure Network architectures

Network architectures

When planning or designing any service or application deployment to the cloud it’s imperative you start with a well-architected design. After defining a network strategy based on the previously discussed best practices, an organization can apply that to the architecture that meets their needs. The following architectures are just a few of the commonly used examples and how the best practices for network security are applied to them.

Cloud native

In recent years, it is entirely possible that a company was created and running with an entirely cloud-based set of services, which means they have no on-prem servers running, and they are using SaaS applications and hosting their service purely in the cloud. The following graphic depicts a simple cloud-native architecture where the organization might be using a few public services. The company has deployed its web application in Azure using purely PaaS services. This architecture is simple and can be secured by leveraging firewall features built into storage and SQL PaaS. Storage and SQL could be configured to block internet access and restrict it to the App Service web app. The following list covers some advantages and disadvantages:

  • Advantages

    • Simple

    • Leverages network security services built into PaaS

  • Disadvantages

    • Traffic is not routed through any central controlling service or device.

    • Each PaaS service has its own network security configuration.

Figure 2-3 shows a simple cloud-only set of services that an organization might be using.

FIGURE 2-3

FIGURE 2-3 Diagram of cloud-only native services

As you can see from the next example, most architectures are not that simple. A startup may be, but as the company’s service grows, it may need to expand to something more complex. Picture a company that has built a purely cloud-based application. It needs to deliver this application globally to its customers.

Here the application is global, which means traffic needs to be load balanced for both HTTP(s) and non-HTTP(s) traffic using Front Door and Traffic Manager. Front Door and Traffic Manager provide that load balancing. Web Application Firewall (WAF) is enabled on Front Door to defend the application at the network edge. Moving deeper in the stack, application gateway is then used in each region to load balance traffic to the VMs running the web application. WAF is also enabled on App Gateway to further protect the application. Why? WAF on Front Door supports geo-filtering, rate limiting, and Azure managed default rule sets, whereas WAF on App Gateway supports ModSec Core Rulesets (CRS). WAF is covered in depth in Chapter 5, “Secure application delivery with Azure Web Application Firewall.” As another protection, DDoS Protection Standard is enabled in the tenant and applied to all virtual networks. DDoS protects any public IPs (PIP) of the application gateways in this architecture. DDoS is covered in Chapter 6. Lastly, NSGs are added to control east-west traffic. This layered approach provides additional defense in depth to the application. Following are the advantages and disadvantages:

  • Advantages

    • Leverages network security at all layers.

    • Various network security services provide protection against many types of attacks.

  • Disadvantages

    • Traffic between virtual networks is not routed through any central controlling service or device.

    • Each PaaS service has its own network security configuration.

Figure 2-4 is an architecture for a global web application with the various services used across the regions.

FIGURE 2-4

FIGURE 2-4 Complex global web application

Hybrid connectivity

Next up are more common architectures used as there are many organizations with existing on-premise networks that need to be connected to Azure and their workloads deployed there.

ExpressRoute with VPN (ER/VPN) failover

In this architecture, ExpressRoute provides a connection that does not route over the internet and, in case of failure, a VPN backup path. The traffic is secured from on-premise to Azure. Once in Azure, WAF on App Gateway protects the web tier. Each subnet has an NSG to limit and contain traffic to only what is needed with rules appropriate for each subnet. For example, a rule to allow RDP or SSH from the management subnet IP range to the web tier and business tier IP range. The SQL database is configured with a service endpoint to provide direct connectivity to the service. No services or VMs have public internet access in this architecture. The following are the advantages and disadvantage:

  • Advantages

    • Various network security provides protection against attacks.

    • Connectivity from on-premise is secure.

    • Remote management is secured from the management subnet only.

  • Disadvantage

    • Traffic between virtual networks is not routed through any central controlling service or device.

Figure 2-5 is an ER/VPN architecture where on-premise connects to Azure over ExpressRoute and VPN.

FIGURE 2-5

FIGURE 2-5 ER/VPN architecture

DMZ

The DMZ (demilitarized zone) architecture enables a secure hybrid network that extends an on-premises network to Azure. This forces traffic coming from on-premise bound for the internet to route through the network virtual appliance (NVA) in the cloud. The advantage to this design is that all traffic passes through the NVA, which can control and provide advanced inspection of the traffic. Because the NVA has a PIP, applying DDoS to protection against attacks adds another layer of protection to the workload. The following are the advantages and disadvantage:

  • Advantages

    • Traffic is routed through a central device, which can control and limit traffic flows.

    • Various network security services provide protection against many types of attacks.

  • Disadvantage

    • NVA requires additional management and configuration for HA.

Figure 2-6 shows the DMZ architecture and connections.

FIGURE 2-6

FIGURE 2-6 DMZ architecture

Expanding on this architecture, in Figure 2-7 we see that the architecture layers in Azure Bastion, which provides secure RDP (remote desktop protocol) and SSH (secure shell) access to the virtual machines. Azure Firewall has replaced the NVA to provide a cloud native approach. Azure Firewall has the advantages of being a fully managed PaaS. It can auto-scale as needed and provide built-in high availability. With an NVA, organizations must manage high availability, load balancing, and the appliance software themselves. Following are the advantages and disadvantage:

  • Advantages

    • Cloud native services such as Azure Firewall and Bastion require less management and configuration.

    • Key traffic is routed through a central device, which can control and limit traffic flows.

    • Various network security services provide protection against many types of attacks.

  • Disadvantage

    • Workloads are not fully isolated behind the firewall.

FIGURE 2-7

FIGURE 2-7 DMZ architecture with Azure Bastion

Hub and spoke

The hub virtual network acts as a central point of connectivity for on-premise networks, meaning on-prem is just another spoke. All traffic is routed through the hub virtual network. The spoke virtual networks create an isolated network to contain traffic to the specific workloads. This could be spokes for prod versus dev or workload or front end vs back end. Central services could be deployed in the hub as a separate subnet or a spoke virtual network. In the hub, Azure Firewall or an NVA is deployed to provide additional protection to east-west traffic between the spokes. This is an ideal architecture because it allows for expansion and contraction over time by adding or removing spokes. For multiregion, additional hubs are deployed to the region with region spokes connected. Hubs between regions can be connected using vNet peering, site-to-site VPN, or virtual WAN. The main difference between virtual WAN and hub and spoke is that virtual WAN is a managed offering. The following are the advantages and disadvantages:

  • Advantages

    • Central services can provide cost savings by sharing them across workloads.

    • Hub virtual network can create separation of duties for IT (security, infrastructure) and workload (DevOps).

  • Disadvantages

    • It is complex to manage as spoke numbers grow.

    • Spoke-to-spoke traffic must pass through the hub.

Figure 2-8 is a hub and spoke architecture.

FIGURE 2-8

FIGURE 2-8 Hub-and-spoke architecture

Azure Virtual WAN

Azure vWAN is a service that brings together all of the benefits of previously discussed hybrid architectures into a single interface. Virtual WAN (vWAN) includes functionalities for branch, site-to-site VPN, point-to-site VPN, ExpressRoute, intra-cloud connectivity, routing, and Azure Firewall. vWAN is built on the hub and spoke architectures and enables global network connectivity.

The following resources are part of vWAN:

  • virtualWAN This resource is an overlay of the Azure network and contains multiple resources.

  • Hub This is a Microsoft-managed virtual network. It contains various endpoints like VPN Gateway and ExpressRoute gateway to provide connectivity to on-premise or mobile users.

  • Hub virtual network connections This is a connection resource to connect the hub to spoke virtual networks.

  • Hub-to-hub communication Hubs are deployed in regions and connected to each other in the virtual WAN. This creates a full-mesh architecture allowing traffic between virtual networks, on-premise, and branch sites.

  • Hub route table This allows the addition of routes to the hub route table.

Figure 2-9 is the basic diagram of vWAN.

FIGURE 2-9

FIGURE 2-9 vWAN

Connectivity

Virtual WAN provides many types of connectivity, and the advantage is that an organization can use one or all of the various types. They can start with one that is needed today and expand over time as new connectivity requirements arise. There are various methods to connect on-premise to virtual WAN. Site-to-site VPN connections allow on-premise connectivity over an IPSec/IKE connection. Organizations must employ a VPN device or virtual WAN partner device on-premise to establish the S2S VPN. If there is a need for mobile users to have VPN access, a virtual WAN can be configured to provide VPN for users and require a VPN client on the endpoint. ExpressRoute lets organizations connect over a private connection.

Transit connectivity is also provided in virtual WAN. Once connected to the hub, on-premise traffic can be routed to spoke virtual networks. This means user traffic coming from on-prem will route over S2S VPN or ExpressRoute, hit the hub, and use the virtual network connection to the spoke to reach a server. This traverses the same path the opposite way. Virtual WAN also allows transit connectivity between VPN and ExpressRoute. A mobile user over VPN could reach on-premise via the hub. Spoke virtual networks can talk to each other through the hub. Traffic can travel between two spokes via the hub. Multiple hubs can be added to virtual WAN as well. This will allow spoke virtual networks to talk over the hub-to-hub connection going from spoke to hub to the other hub to the other spoke.

Security

Virtual WAN allows organizations to apply virtual hub routing and manage traffic flow within the virtual WAN. Specifically, this can be used to isolate virtual networks, create shared services virtual networks, or route traffic through one of the Azure partner NVAs or Azure Firewall. There is also an option to use Azure Firewall in the hub and integrate partner offerings like zScaler, iBoss, and Checkpoint. In this configuration, Azure Firewall protects private traffic in the hubs and internet/SaaS traffic is routed to the partner service. An organization might have a need to isolate the virtual networks allowing traffic from on-premise to all virtual networks but not virtual network to virtual network. Or perhaps, the organization wants to configure shared services such as domain controllers or file services but doesn’t want to allow all virtual network to virtual network traffic. By applying routing these scenarios are achievable.

In the Shared Services example, nonshared services virtual networks do not learn routes to other nonshared virtual networks but do learn about the shared services virtual network. Shared services are propagated to all virtual networks and branches/VPN using the default table. It is important to understand how routing can be used to limit traffic to only sources and destinations needed. Figure 2-10 depicts an example of the shared services routing.

FIGURE 2-10

FIGURE 2-10 Shared services routing

To layer in security, organizations can deploy an NVA into a virtual network. When using NVA, spokes must be created off of the NVA virtual network that resides in the virtual WAN. This will allow having traffic from workload virtual networks to pass through the NVA. Figure 2-11 shows the NVA VNet added with spokes behind it.

FIGURE 2-11

FIGURE 2-11 NVA VNet

If an organization wants to use cloud native network security, vWAN offers a secure virtual hub, which includes an Azure Firewall instead of using an NVA. Figure 2-12 shows the difference that additional spoke networks are not needed because Azure Firewall can be deployed in the vWAN hub.

FIGURE 2-12

FIGURE 2-12 vWAN with Azure Firewall