A solution architecture for Azure PaaS services using your own firewall

 23 Feb 2020 -  Remco Brosky

Securing your web sites and web applications has many aspects. A customer asked me to control the flow to his webapplications in Azure AppServices. So, I came up with this architecture and thought I’d share it with you. The basics can also be used to secure applications that reside within the network (like a private AKS cluster, running apps on a VM or even on-prem or on the egde).

In this case we would like to use App Services and some other Azure services like SQL DB and Blob Storage. All these services have public endpoints, and therefor it’s harder to control with a firewall. So, consider this picture, which represents the architecture I came up with.

solution architecture 1

Parts of the architecture

I always compare Azure with a box of lego’s, the building blocks for our solutions. The following building blocks are used

Virtual Network Setup

Although you can establish this entire setup in a single VNET, I’ve created a hun and spoke network architecture. This is a reference Architecture that can be found in here on docs.microsoft.com. Using this setup gives you a lot of flexibility and can facilitate hybrid network setups, extending your on-prem network to Azure.

VNET-HUB The HUB network is where all traffic from all the networks come together and it allows you to peer more VNET’s (spokes) to the hub and route the traffic through the hub from one spoke to another. When you need connectivity between VNET’s (e.g. because the VNET’s are in different subscriptions) you don’t need to peer all VNET’s to all other VNET’s. Just peer the VNET’s to the hub and have a way of routing traffic by using a firewall or other kind of routing device. It’s a good practice to place “Shared Services” into the hub. Think of custom DNS servers, routers, firewalls or domain controllers.

VNET-SPOKE This is the spoke network. In this case the spoke is populated with private endpoints of a storage account and a SQL DB and had a subnet for the webapp. The Webapp subnet is used to configure VNET integration from the WebApp to the internal network.

*Note: Since VNET integration uses a subnet for each integration the WebAppSubnet is really small x.x.x.x/29, so we don’t waste any ip adresses. VNET Integration is still in preview but works very well. It allows you to access internal endpoints from the webapp. We will be using this to allow the webapp to connect to the private endpoints of the database and the storage account. *

Azure Firewall

In this case I’ve used Azure Firewall, but it could be any other firewall solution from the Azure Marketplace. The firewall has a public IP Address and a private address on the subnet. This way traffic flows throught the firewall and rules can be applied. Note on the AzureAppGwSubnet and the WebAppSubnet there are custom route tables forcing all traffic from the subnet to the firewall using this rule.

0.0.0.0/0 next hop -> virtual appliance -> <private ip of the firewall>

The firewall contains a DNAT Rule to route incoming traffic on port 443 (https) to the Application Gateway The firewall contains a Network Rule to allow traffic coming from the application gateway to the internet

Application Gateway

The Application Gateway is a HTTP(s) loadbalancer/router. It allows you to route traffic based on a port or a hostname to a specific endpoint (called a backend pool). It has support for Azure AppServices (which have a specic way of routing traffic, based on a host header name, and use specific SSL Certs for HTTPS traffic). It also has (optionaly) a Web Application Firewall that is able to detect a number of different threats to your webapplication. The Application Gateway in this architecture is not exposed to the internet, bus has a private ip only. It’s the central HTTP(s) router for all webtraffic in the network. The Route table in the subnet forces the Application Gateway route through the firewall. This way we can control the flow of traffic. Application Gateway and App Services on docs.microsoft.com

Web App

Of course there is also an option to use a full-internal service like App Service Environment or another application platform like AKS, but WebApps are still superpopulair, wasy to use and give you a lot of option to run all kind of web applications (windows/linux, containers, Node, PHP, .NET, .NET Core etc…). The whole point of this setup is to use the public PaaS service in a secure way, even be able to allow access to your webapp from the internal network only, so use it as an intranet application. The two things to do on our webapp can be found in the Networking section of the Web App in the Azure Portal.

VNET Integration This will allow the webapp to connect to internal endpoints (like the SQL DB) in our network. I’ve used Add VNET (Preview) for this, which is much simpeler than the classic feature. The classic feature provisions a VPN connection. The VNET you would like to connect to needs a VPN Gateway for this to work. The preview feature doesn’t have this requirement and is much more lightweight…and works like a charm. When you need to connect to the SQL DB, you’ll need its internal address or DNS name in the Web App configuration to be able to access it. App Services VNET integration on docs.microsoft.com

Access Restrictions We will only allow traffic coming from the Public IP of our firewall. Try connecting to your webapp on it’s appname.azurewebsites.net address after this. You will see a notification that the webapp is not running when your address is not whitelisted. App Services IP Restrictions on docs.microsoft.com

SQL DB and Storage Account

For both services a relatively new feature is available to increase your security. It’s called a “Private Link” or “Private EndPoint”. When using a private link, your SQL DB or storage account is connected to a Network Interface in the internal network. This way the service has an internal IP and can be enclosed in the internal DNS with any name you would like. On the service itself (e.g. SQL DB) set its firewall to “NOT” Allow Azure Services and don’t allow any extenal IP’s to access it. This way the only way to connect to the database is thought the internal network (or the Azure Firewall if you would need external access). [Private Endpoint on docs.microsoft.com] (https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-overview)

I also have a demo setup on Github for SQL DB private endpoints. You can access and provision the ARM templates here for a complete demo. Private Link Demo on github.com

Conclusion

With this architecture you get a pretty good idea what you could build and how to restrict access to public PaaS services and control the flow to access them. The Hub and Spoke network architecture is used, because a lot of enterprises don’t have an Azure-only setup and have a hybrid setup. It further shows you how to apply features on the Azure platform to a number of services to get a much higher security grade. There are of course several solutions to obtain a higher security. Services like Azure Frontdoor also work in this space, but this is a full hybrid solution. Also, my customer has a second Azure region with the same setup for failover purposes, so in the actual case we’ve also used a traffic manager to be able to load-balance over Azure Regions. The traffic manager is using the Firewall Public IP’s in both regions as targets. So, you see it’s pretty easy to expand on these scenario’s once your workload start growing and you have more requirements.

If you going to try to build this, start with a web app, connect it to a SQL DB and then start restricting access more and more.

If you have questions or remarks based on this post, please feel free to drop me an email at remco@cloudroute.nl.