Pattern implementation for network secure ingress

Network secure ingress encapsulates several design patterns, including the patterns for global routing, global offloading, and health endpoint monitoring. You can use the pattern implementation in this article as a gateway for most HTTP or HTTPS workloads that require high availability or reliability by providing secure global routing to workloads in different regions with health-based origin failover.

Video: Network secure ingress implementation

Pattern requirements

This article describes three requirements that the pattern implementation for network secure ingress focuses on: global routing, health-based origin failover, and attack mitigation at the edge.

Global routing

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

Health-based origin failover

The implementation must identify healthy and unhealthy origins and route requests away from unhealthy origins. The health-probe interval and sample settings determine how quickly Azure Front Door detects a change in origin health. Configure these settings to meet the workload's failover target without causing unnecessary failovers.

Mitigating attacks at the edge

Mitigating attacks at the edge necessitates the "network secure" part of the implementation. The workloads or platform as a service (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.

Patterns

This solution implements the following design patterns:

• Gateway routing pattern: Route requests to multiple services or service instances that can reside in different regions.
• Gateway offloading pattern: Offload functionality, such as mitigating attacks, to a gateway proxy.
• Health endpoint monitoring pattern: Expose endpoints that validate the health of the workload.

Design

The diagram shows an HTTPS request flowing to an Azure Front Door Premium box, which has a web application firewall in it. This illustration shows the integration between Azure Front Door Premium and Azure Web Application Firewall. The diagram then shows the request flowing through Private Link to two stamps in different regions. Each stamp has a static website and an internal load balancer. The requests flow through Private Link to the static websites and the load balancers in both stamps.

This implementation includes the following details:

• It uses Azure Blob Storage accounts to simulate static web workloads running in two regions. This implementation doesn't include any workloads running behind an internal load balancer (ILB). The diagram shows an ILB to illustrate that this implementation would work for private workloads running behind an ILB.

• It uses Azure Front Door Premium tier as the global gateway.

• The Azure Front Door instance has a global web application firewall (WAF) policy configured with managed rules that help protect against common exploits.

• The storage account firewalls deny public network access so that clients can't bypass Azure Front Door and its security controls.

• The Azure Front Door Premium tier accesses the storage accounts via Azure Private Link.

• The Azure Front Door instance has the following high-level configuration:

  • An endpoint with a single route that points to a single origin group. An origin group is a collection of origins.

  • The origin group has an origin configured to point to each storage account.

  • Each origin requests Private Link access to the storage account.

  • The origin group has health probes configured to access an HTML page in the storage accounts. The page verifies the availability of the static workload. For application workloads, use a health endpoint that checks the critical dependencies required to serve requests.

    This implementation considers an origin healthy when three of the last four probes succeed. The probe interval and sample settings determine how quickly Front Door detects a change in origin health.

Components

• Azure Web Application Firewall is a security service that protects web applications from common threats and vulnerabilities by using Microsoft-managed rule sets. In this architecture, Azure Web Application Firewall integrates with Azure Front Door Premium to inspect and block malicious HTTP and HTTPS traffic before it reaches origins.

• Azure Private Link is a service that enables private connectivity to Azure PaaS services over the Microsoft backbone network. In this architecture, it allows Azure Front Door to securely access storage accounts without exposing them to the public internet.

• Azure Front Door Premium is a global application delivery network that provides layer-7 load balancing, routing, and security features. In this architecture, it serves as the secure global gateway. It routes traffic to regional workloads and enforces Web Application Firewall policies while communicating privately via Private Link. The Premium tier supports the following components:

  • Private Link enables Azure Front Door to connect to PaaS services or workloads in a private virtual network. In this architecture, Azure Front Door uses Private Link to reach each storage origin without traversing the public internet.

  • Microsoft-managed rule sets are available only in the Premium tier of Azure Front Door. In this architecture, Azure Web Application Firewall uses managed rules to inspect incoming requests and block requests that reach the configured anomaly-score threshold.

• Azure Storage is a scalable cloud storage service for structured and unstructured data. In this architecture, Blob Storage accounts store static web assets and serve as the origin targets for Azure Front Door routing.

• An ILB distributes private IP traffic within a virtual network or across connected networks. In this architecture, expose the origin web servers behind the ILB through an Azure Private Link service so that Azure Front Door can use the ILB as a custom private origin.

Operations

Securing resources from a network perspective helps protect against exploits, but it 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 access to network-secured resources for operational purposes, this implementation deploys a virtual machine (VM) in a virtual network that has Private Link access to the storage accounts. This implementation deploys Azure Bastion, which the administrator can use to connect to the VM. For the deployment scenario, you could deploy a private build agent to the virtual network, similar to how the VM was.

Here are details about the components for operations:

• Azure Virtual Network is a networking service that enables secure communication between resources. In this architecture, the virtual network contains the components required for an administrator to securely communicate with the storage account over the private Microsoft backbone network.

• Azure Virtual Machines is an infrastructure-as-a-service (IaaS) offering that provides scalable compute resources. In this architecture, a VM serves as a jump box for administrators to securely access network-secured resources.

• Azure Bastion is a managed PaaS that provides Remote Desktop Protocol (RDP) and Secure Shell (SSH) access to VMs without exposing public IP addresses. In this architecture, it enables administrators to connect to the jump box VM over SSH for secure operations.

• A private endpoint is a network interface that connects to Azure services through Private Link and uses a private IP address from the virtual network. In this architecture, the private endpoint connects resources in the virtual network to the storage account over its private IP address.

• A private Azure DNS zone is a Domain Name System (DNS) service that resolves domain names to private IP addresses within a virtual network. In this architecture, it resolves the storage account's Private Link host name to its private IP address, which enables secure access from the VM.

Web request flow

The diagram shows a user making a web request to Azure Front Door. In the Azure Front Door box, the diagram shows each of the steps of the Azure Front Door routing flow. The flow highlights the step where WAF rules are evaluated, where the Azure Front Door route is matched and an origin group is selected, and where the origin is selected from the origin group. The last highlighted piece is where Azure Front Door connects to the Azure Blob Storage account via Private Link.

1. The user issues an HTTP or HTTPS request to an Azure Front Door endpoint.

2. The WAF rules are evaluated. Managed rules that use anomaly scoring add to the request's anomaly score when they match. This architecture runs in prevention mode, and WAF applies the Block action when the request reaches the anomaly-score threshold. Blocked requests don't reach an origin.

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 website.

4. The origin is selected from the origin group.

   a. In this example, the health probes deemed the website unhealthy, so it's eliminated from the possible origins.
   b. This website is selected.

5. The request is routed to the Azure Storage account through Private Link over the Microsoft backbone network.

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

Operational flow

The diagram has three parts. The first part shows Azure Blob Storage acting as a static website. Azure Front Door connects through Private Link to the storage account. The second part is a box that represents a virtual network. The virtual network has subnets and their contents. These subnets include a private endpoint subnet that contains a private endpoint with an IP address of 10.0.2.5, a jump box subnet with a jump box virtual machine, and an Azure Bastion subnet with Azure Bastion in it. The third part is an administrative user who is using SSH to access the jump box VM in the virtual network via Azure Bastion. An arrow goes from the VM to the private Azure DNS zone. The last arrow goes from the VM to the private endpoint and then to the storage account.

1. An administrator connects to the Azure Bastion instance that's deployed in the virtual network.

2. Azure Bastion provides SSH connectivity to the jump box VM.

3. The administrator on the jump box tries to access the storage account via the Azure CLI. The jump box queries DNS for the public Azure Blob Storage account endpoint: storageaccountname.blob.core.windows.net.

   The public DNS name is an alias for storageaccountname.privatelink.blob.core.windows.net. The private Azure DNS zone resolves that name to the private endpoint's IP address, which is 10.0.2.5 in this example.

4. The jump box connects to the storage account through the private endpoint.

Considerations

Keep the following points in mind when you use this solution.

Reliability

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

Consider the following reliability implications when you use this pattern:

• Deploy redundant origins in separate regions, and configure health probes so that Azure Front Door routes requests only to origins that can serve them. Define a failover target based on workload requirements, and tune the probe interval, sample size, and required successful samples to meet that target without causing unnecessary failovers.

• Keep content consistent across the storage origins. Publish the same versioned release to each Storage account. If you use object replication, account for asynchronous replication.

• Test origin failure and recovery regularly. Validate failure detection, routing to a healthy origin, and failback behavior. If every origin in an origin group fails its health probes, Azure Front Door treats all origins as unhealthy and distributes requests across all of them in a round-robin pattern.

• For origins that use Private Link, configure origins with different Azure Front Door Private Link regions. This configuration provides separate paths through the Azure Front Door regional clusters. Select a supported Private Link region near each origin to limit the latency of the extra network hop.

• Azure Front Door remains the single global ingress service in this design. For a mission-critical workload that can't tolerate an Azure Front Door outage, evaluate a tested alternate ingress path. An alternate path increases cost and operational complexity because you must maintain equivalent routing, security, certificate, monitoring, and failover configurations.

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.

Use the following security practices when you implement this pattern:

• Configure each origin to reject traffic that doesn't arrive through Azure Front Door. For the storage origins in this implementation, use the storage account firewall to deny public network access and approve the private endpoint connection that Azure Front Door manages.

• Use the latest available Default Rule Set. Keep production policies in prevention mode.

• Apply WAF exclusions and rule overrides at the narrowest practical scope. Prefer a rule-level exclusion for a specific request attribute over disabling a rule or rule group.

• Use Bot Manager rules and rate-limit rules.

• Enable resource activity, Azure Front Door access, WAF, and health-probe logs. Send the logs to the workload's monitoring and security systems, and configure alerts for unexpected increases in WAF rule matches or blocked requests, origin health failures, and changes to WAF policies. For more information, see Monitor metrics and logs in Azure Front Door.

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.

Azure Front Door Premium costs more than the Standard tier. The Premium tier includes managed WAF rules and Private Link origin support. Review the following resources to learn more about pricing for Azure Front Door and Web Application Firewall:

• Azure Front Door pricing
• Web Application Firewall pricing
• Azure pricing calculator

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 to operations and deployment. Keep these points in mind:

• The IP ranges for Microsoft-hosted agents vary over time. Consider implementing self-hosted agents in your virtual network.
• Implement Azure Bastion for scenarios where operations teams need to access network-secured resources.

Performance efficiency

Performance efficiency is the ability of your workload to scale to meet the demands that users place on it. For more information, see Overview of the performance efficiency pillar.

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

Next step

Architecture best practices for Azure Front Door