Microsoft Shares Interesting Secure Azure Network Design
Microsoft recently shared a detailed design for a secure network (or DMZ) deployment in Azure, based on the United Kingdom’s cloud security principles. The focus of Microsoft’s article was on the UK, but we can use this design as a basis for other deployments.
What is “Inside Microsoft Teams”?
“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts. Our next episode, “Polaris Inc., and Microsoft Teams- Reinventing how we work and play” will be airing on Oct. 28th from 10-11am PST.
UK Cloud Security Principles
The set of guidelines that steered the design that Microsoft has shared is from the UK government, and these principles are supposed to help potential cloud customers find and deploy a secure service in the cloud.
The secure network design that Microsoft created is intended to meet the requirements of the Cloud Security Principles, but when you look at what is in the design, you have to admit that anyone wanting a secure network in Azure should consider this design, no matter what country they are in. Even better, Microsoft has shared the JSON templates for deploying this design in your own Azure subscription!
The Microsoft Azure network design for UK Cloud Security Principles [Image Credit: Microsoft]
Understanding the Design
The design is quite comprehensive, and brings together many elements that have been shared by Microsoft in many disparate documents; this is why I like this “UK” network design.
Let’s start with management; the concept of a “jump box” is being used for remote management. A virtual machine is deployed into a separate management virtual network (VNet). The management VNET is peered with the operational VNet and this is where the service runs. Remote Desktop does not have to be opened up via NAT to each of the application/service virtual machines. Instead, when an administrator needs to log into one of the service virtual machines, they remote into the jump box and then remote, via the peered connection, to the required virtual machine in the operational VNet.
The service running the operational VNet is made available via two possible means (both or either can be deployed). A gateway is deployed in the operational VNet in a dedicated gateway subnet; this provides the Azure customer with private access to the service via either a VPN connection or an ExpresRoute (WAN) connection.
A web application gateway provides layer 7 load balanced access to web servers, with optional (still in preview) web application firewall functionality. An option that one might consider is to do the following to either supplement or replace the web application gateway:
- Create another subnet in the operational VNET
- Deploy load balanced (Azure load balancer) third-party network virtualization appliances for load balancing and/or security at layer 4 and layer 7
Every tier of the service is placed into its own subnet. An availability set ensures anti-affinity for the virtual machines, and a network security group enforces layer 4 security rules. Each network security group, one for each subnet, only allows the minimum required protocols and ports. For example, the web subnet allows TCP 80/443 from outside of the VNet and RDP from the jump box subnet, and nothing more. The Data subnet will allow database traffic from the Biz subnet and RDP from the jump box subnet, and nothing more. The ADDS subnet allows traffic in from subnets containing domain members and RDP from the jump box subnet, and nothing more.
A Web subnet contains two or more load-balanced web servers. A Biz subnet contains application servers, and a Data subnet contains database servers. Note that this separation of service tiers into different subnets uses Microsoft’s best practices for designing subnets and network security groups; each domain of security should have its own subnet, and each subnet should have its very own network security group.
Many Microsoft-based applications require an Active Directory domain. In some scenarios, where single sign-on is just the requirement, using Azure AD Connect or ADFS in conjunction with Azure AD Domain Services might suffice. But if you need to integrate on-premises and in-Azure machines and services, then you need to extend your Active Directory into Azure by using Azure virtual machines as domain controllers. In the above design, domain controllers are deployed into another subnet in the Operations VNet.
If you like this design, no matter where you are, then you can deploy it easily enough. Microsoft has shared it on GitHub as three JSON templates, which you can download and customize or deploy straight into your Azure subscription.
More Azure Architectures
If you like the idea of what Microsoft has done with the UK Cloud Principles, then you should check out the Azure Reference Architectures. Here you will find a number of virtual machine and VNet designs, accompanied by the JSON templates that you can deploy.