Skip to content

Latest commit

 

History

History
124 lines (85 loc) · 9.5 KB

secure-vnet-dmz.md

File metadata and controls

124 lines (85 loc) · 9.5 KB
title description author ms.date pnp.series.title pnp.series.next pnp.series.prev cardTitle
Implementing a DMZ between Azure and the Internet
How to implement a secure hybrid network architecture with Internet access in Azure.
telmosampaio
11/23/2016
Network DMZ
nva-ha
secure-vnet-hybrid
DMZ between Azure and the Internet

DMZ between Azure and the Internet

This reference architecture shows a secure hybrid network that extends an on-premises network to Azure and also accepts Internet traffic.

0

Download a Visio file of this architecture.

This reference architecture extends the architecture described in Implementing a DMZ between Azure and your on-premises datacenter. It adds a public DMZ that handles Internet traffic, in addition to the private DMZ that handles traffic from the on-premises network

Typical uses for this architecture include:

  • Hybrid applications where workloads run partly on-premises and partly in Azure.
  • Azure infrastructure that routes incoming traffic from on-premises and the Internet.

Architecture

The architecture consists of the following components.

  • Public IP address (PIP). The IP address of the public endpoint. External users connected to the Internet can access the system through this address.
  • Network virtual appliance (NVA). This architecture includes a separate pool of NVAs for traffic originating on the Internet.
  • Azure load balancer. All incoming requests from the Internet pass through the load balancer and are distributed to the NVAs in the public DMZ.
  • Public DMZ inbound subnet. This subnet accepts requests from the Azure load balancer. Incoming requests are passed to one of the NVAs in the public DMZ.
  • Public DMZ outbound subnet. Requests that are approved by the NVA pass through this subnet to the internal load balancer for the web tier.

Recommendations

The following recommendations apply for most scenarios. Follow these recommendations unless you have a specific requirement that overrides them.

NVA recommendations

Use one set of NVAs for traffic originating on the Internet, and another for traffic originating on-premises. Using only one set of NVAs for both is a security risk, because it provides no security perimeter between the two sets of network traffic. Using separate NVAs reduces the complexity of checking security rules, and makes it clear which rules correspond to each incoming network request. One set of NVAs implements rules for Internet traffic only, while another set of NVAs implement rules for on-premises traffic only.

Include a layer-7 NVA to terminate application connections at the NVA level and maintain compatibility with the backend tiers. This guarantees symmetric connectivity where response traffic from the backend tiers returns through the NVA.

Public load balancer recommendations

For scalability and availability, deploy the public DMZ NVAs in an availability set and use an Internet facing load balancer to distribute Internet requests across the NVAs in the availability set.

Configure the load balancer to accept requests only on the ports necessary for Internet traffic. For example, restrict inbound HTTP requests to port 80 and inbound HTTPS requests to port 443.

Scalability considerations

Even if your architecture initially requires a single NVA in the public DMZ, we recommend putting a load balancer in front of the public DMZ from the beginning. That will make it easier to scale to multiple NVAs in the future, if needed.

Availability considerations

The Internet facing load balancer requires each NVA in the public DMZ inbound subnet to implement a health probe. A health probe that fails to respond on this endpoint is considered to be unavailable, and the load balancer will direct requests to other NVAs in the same availability set. Note that if all NVAs fail to respond, your application will fail, so it's important to have monitoring configured to alert DevOps when the number of healthy NVA instances falls below a defined threshold.

Manageability considerations

All monitoring and management for the NVAs in the public DMZ should be performed by the jumpbox in the management subnet. As discussed in Implementing a DMZ between Azure and your on-premises datacenter, define a single network route from the on-premises network through the gateway to the jumpbox, in order to restrict access.

If gateway connectivity from your on-premises network to Azure is down, you can still reach the jumpbox by deploying a public IP address, adding it to the jumpbox, and logging in from the Internet.

Security considerations

This reference architecture implements multiple levels of security:

  • The Internet facing load balancer directs requests to the NVAs in the inbound public DMZ subnet, and only on the ports necessary for the application.
  • The NSG rules for the inbound and outbound public DMZ subnets prevent the NVAs from being compromised, by blocking requests that fall outside of the NSG rules.
  • The NAT routing configuration for the NVAs directs incoming requests on port 80 and port 443 to the web tier load balancer, but ignores requests on all other ports.

You should log all incoming requests on all ports. Regularly audit the logs, paying attention to requests that fall outside of expected parameters, as these may indicate intrusion attempts.

Solution deployment

A deployment for a reference architecture that implements these recommendations is available on GitHub. The reference architecture can be deployed either with Windows or Linux VMs by following the directions below:

  1. Click the button below:
  2. Once the link has opened in the Azure portal, you must enter values for some of the settings:
    • The Resource group name is already defined in the parameter file, so select Create New and enter ra-public-dmz-network-rg in the text box.
    • Select the region from the Location drop down box.
    • Do not edit the Template Root Uri or the Parameter Root Uri text boxes.
    • Select the Os Type from the drop down box, windows or linux.
    • Review the terms and conditions, then click the I agree to the terms and conditions stated above checkbox.
    • Click the Purchase button.
  3. Wait for the deployment to complete.
  4. Click the button below:
  5. Once the link has opened in the Azure portal, you must enter values for some of the settings:
    • The Resource group name is already defined in the parameter file, so select Create New and enter ra-public-dmz-wl-rg in the text box.
    • Select the region from the Location drop down box.
    • Do not edit the Template Root Uri or the Parameter Root Uri text boxes.
    • Review the terms and conditions, then click the I agree to the terms and conditions stated above checkbox.
    • Click the Purchase button.
  6. Wait for the deployment to complete.
  7. Click the button below:
  8. Once the link has opened in the Azure portal, you must enter values for some of the settings:
    • The Resource group name is already defined in the parameter file, so select Use Existing and enter ra-public-dmz-network-rg in the text box.
    • Select the region from the Location drop down box.
    • Do not edit the Template Root Uri or the Parameter Root Uri text boxes.
    • Review the terms and conditions, then click the I agree to the terms and conditions stated above checkbox.
    • Click the Purchase button.
  9. Wait for the deployment to complete.
  10. The parameter files include hard-coded administrator user name and password for all VMs, and it is strongly recommended that you immediately change both. For each VM in the deployment, select it in the Azure portal and then click Reset password in the Support + troubleshooting blade. Select Reset password in the Mode drop down box, then select a new User name and Password. Click the Update button to save.