Network secure ingress pattern implementation with Azure Front Door Premium tier

Network secure ingress encapsulates several design patterns, including the global routing, global offloading, and health endpoint monitoring patterns. This pattern implementation can be used a gateway for any HTTP(S) workload that requires high availability or reliability by providing secure global routing to workloads in differing regions with low latency failover.

Pattern requirements

This article focuses on three requirements that the network secure ingress pattern implementation focuses on: global routing, low latency failover, and mitigating attacks at the edge.

Global routing

The network secure ingress pattern encapsulates the global routing pattern. As such, the implementation is able to route requests to workloads in different regions.

Figure 1: Global routing

Low latency failover

The implementation must be able to identify healthy and unhealthy workloads and adjust the routing accordingly in a time sensitive manner. The latency should be able to support adjusting the routing in a manner of minutes.

Figure 2: Low latency failover

Mitigating attacks at the edge

Mitigating the attacks at the edge necessitates the “network secure” part of the implementation. The workloads or PaaS services shouldn't be accessible via the internet. Internet traffic should only be able to route through the gateway. The gateway should have the ability to mitigate exploits.

Figure 3: Mitigating attacks at the edge

Patterns

This solution implements the following design patterns.

Design

Figure 4: Azure Front Door Premium design

This following are details about this implementation:

• Azure Blob Storage Accounts are used to simulate static web workloads running in two regions. This implementation doesn't implement any workloads running behind an internal load balancer (ILB). The ILB is shown in the diagram to illustrate that this implementation would work for private workloads running behind an ILB.
• Azure Front Door Premium tier is used as the global gateway.
• The Front Door instance has a global Web Application Firewall (WAF) policy configured with Managed Rules that protect against common exploits.
• The Storage Accounts aren't exposed over the internet.
• Azure Front Door Premium tier accesses the Storage Accounts via Azure Private Link.
• The Front Door instance has the following high-level configuration:
  • An endpoint with a single route pointing to a single origin group. An origin group is a collection of origins or back ends.
  • The origin group has an origin configured that points to each Storage Account.
  • Each origin is requesting Private Link access to the Storage Account.
  • The origin group has health probes configured to access an HTML page in the Storage Accounts. The HTML page is acting as the health endpoint for the static workloads. If the probes are able to successfully access the origin three out of the last four attempts, the origin is deemed healthy.

Components

Web request

• Web Application Firewall (WAF) – Web Application Firewall protects web applications from exploits. The premium tier supports managed rules which Microsoft manages that protect against common exploits.
• Azure Private Link – Private endpoints in Azure Private Link expose an Azure PaaS service to a private IP address in a virtual network. This allows the communication to flow across the Microsoft Backbone network and not on the public internet.
• Azure Front Door Premium tier – Azure Front Door provides layer 7 global load balancing. Azure Front Door has integration with WAF. The premium tier supports:
• Azure Storage Account – Blob Storage Accounts are used in this implementation to represent a static website or workload.
• Internal Load Balancer – While pictured, the internal load balancer isn't used in this implementation. It's pictured to represent a private workload running behind that load balancer. The routing to the Storage Account will be the same as it would to load balancers.

Operations

Securing resources from a network perspective protects against exploits, but also isolates the resources from processes or administrators who might need to access those resources. For example, a build agent in a DevOps pipeline might need to access the Storage Account in order to deploy an update to the web application. Also, an administrator might need to access the resource for troubleshooting purposes.

To illustrate providing access to network secure access for operational purposes, this implementation deploys a virtual machine in a virtual network that has Private Link access to the Storage Accounts. This implementation deploys Azure Bastion that the administrator can use to connect to the virtual machine. For the deployment scenario, a private build agent could be deployed to virtual network similar to how the virtual machine was.

• Azure Virtual Network (VNet) – The virtual network in this implementation is used to contain the components required for an administrator to securely communicate with the Storage Account over the private Microsoft Backbone network.
• Azure Virtual Machine (VM) – This VM is used as a jumpbox for administrators to connect to. The VM is deployed in the private VNet.
• Azure Bastion – Azure Bastion allows the administrator to securely connect to the jumpbox VM over SSH without requiring the VM to have a public IP address.
• Private Link Endpoint – The private endpoint is assigned a private IP address from the VNet and connects to the Storage Account PaaS service. This allows resources in the private VNet to communicate to the Storage Account over the private IP address.
• Private DNS Zone – The Private DNS zone is a DNS service that is used to resolve the Azure Storage Account private link hostname to the private endpoint private IP address.

Web request flow

Figure 5: The design of the request routing flow

1. The user issues an HTTP(S) request to an Azure Front Door endpoint.
2. The WAF rules are evaluated. Rules that match are always logged. If the Front Door WAF policy mode is set to prevention and the matching rule has an action set to ‘block on anomaly', the request is blocked. Otherwise the request continues, is redirected, or the subsequent rules are evaluated.
3. The route configured in Azure Front Door is matched and the correct origin group is selected. In this example, the path was to the static content in the web site.
4. The origin is selected from the origin group.
    4a. In this example, the web site was deemed unhealthy by the health probes, so it was eliminated from the possible origins.
    4b. This web site was selected.
5. The request is routed to the Azure Storage Account via private link over the Microsoft backbone network.

For more information about the Azure Front Door routing architecture, see Routing architecture overview.

Operational flow

Figure 6: The design of the administrator flow

1. An administrator connects to Azure Bastion that is deployed in the Virtual Network.
2. Azure Bastion provides SSH connectivity to the jumpbox virtual machine.
3. The administrator on the jumpbox tries to access the storage account via the Azure CLI. The jumpbox queries DNS for the public Azure Blob Storage Account endpoint: storageaccountname.blob.core.windows.net. Private DNS ultimately resolves to storageaccountname.privatelink.blob.core.windows.net, returning the private IP address of the private link endpoint, which is 10.0.2.5 in this example.
4. A private connection to the storage account is established through the private link endpoint.

Considerations

Keep these points in mind when you use this solution.

Reliability

Reliability ensures your application can meet the commitments you make to your customers. For more information, see Overview of the reliability pillar.

This scenario addresses the following key points regarding reliability:

Security

Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Overview of the security pillar.

This scenario addresses the following key points regarding security:

Cost optimization

Cost optimization is about looking at ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Overview of the cost optimization pillar.

While both Azure Front Door Premium and Web Application Firewall Premium provide advanced security features over the standard tier, there's additional cost to both. Review the following resources to learn more about pricing for Azure Front Door and Web Application Firewall:

Operational excellence

Operational excellence covers the operations processes that deploy an application and keep it running in production. For more information, see Overview of the operational excellence pillar.

Implementing network security boundaries adds complexity regarding operations and deployment.

• The IP ranges for Microsoft-hosted agents vary over time. You should consider implementing self-hosted agents in your virtual network.
• Implement Azure Bastion for scenarios where operations teams need to access network secured resources.
• The use of Web Application Firewall (WAF) on Azure Front Door provides centralized protection for HTTP(S) requests is an example of the gateway offloading pattern. The responsibility of examining requests for exploits was offloaded to WAF in Azure Front Door. The benefit from an operational excellence perspective is that there is only one place where the rules need to be managed.

Performance efficiency

Performance efficiency is the ability of your workload to scale to meet the demands placed on it by users in an efficient manner. For more information, see Performance efficiency pillar overview.

Global routing enables horizontal scaling through the deployment of additional resources in the same or different regions.

Deploy this implementation

Follow the steps outlined in the Network Secure Ingress Sample.