The Azure App Service is offered as two deployment types: the multi-tenant service and the App Service Environment. In the multi-tenant service there are thousands of customers on the same infrastructure. Your apps are always secured but the network, the address space and some other components are shared. In an App Service Environment you have a single tenant version of App Service that runs in your Azure Virtual Network. The next two articles are focused on how to configure network security in the multi-tenant App Service.
In this article, you will learn how to secure your standalone app in the multi-tenant App Service. In the next article, we will cover how to build a secure multi-tier web application.
There are two aspects that need to be secured for a web app, inbound traffic and outbound traffic. Inbound traffic are visitors going to your web page, or clients sending requests to your API. Outbound traffic is when your web app makes an outbound call to a database, cache, message queue, or other service. The inbound traffic passes through a load balancer to a set of shared front end servers before reaching the workers which your apps run on. The outbound traffic leaves those workers and goes out through one of the outbound load balancers used by the scale unit. In the diagram below, the inbound and outbound load balancers are shown in green.
All traffic to and from the components inside App Service is strictly locked down and secured to prevent malicious actions. This includes preventing any worker-to-worker communication. This means users just need to secure the networking path to and from their apps–all other traffic is secured for you.
The following tutorial uses a number of Azure Networking features and services. Here is a quick breakdown of the features used in this article.
To secure the network access around your web app you will need to secure…
To secure inbound request traffic to your app, use a WAF enabled Application Gateway with Service Endpoints. To secure inbound publishing traffic to your app, use a build agent with service endpoints on the publishing endpoint. Lastly, to secure outbound traffic from your web app, use VNet Integration and an Azure Firewall.
The end result is that your web app will have all inbound traffic routed through your Application Gateway to your app. You can, and should, enable Web Application Firewall (WAF) support on your Application Gateway.
There are two alternative services that are in preview that should be noted. One is using Private Endpoints rather than Service Endpoints and the other is using Azure Front Door instead of an Application Gateway.
If you use Private Endpoints instead of Service Endpoints, you would create your Private Endpoint in a subnet other than the GatewaySubnet. This Private Endpoint would be configured against your app. This is a great solution as it also hosts the HTTPS publishing endpoint for your app. When you add Private Endpoints to your app, the app is no longer accessible from the internet. Traffic to your app must only go through the private endpoints on your app.
If you use Azure Front Door (AFD) with your app, you would need to set an IP address access restriction to secure your app to only being accessible through AFD. There are some additional changes that will soon be available that will enable you to lock you app down to specific AFD profiles. If you use AFD, you can enable a mix of capabilities such as WAF protection just like with an Application Gateway.
Publishing is the process by which you upload your web app content to your app service instance. Unless you are using FTP, all publishing actions are performed against the scm site for your app. For every app there exists the app url and there also exists the publishing url. The publishing url is <app name>.scm.azurewebsites.net. Secure publishing is not too different from secure app access. For secure publishing you need to publish from inside your VNet. To have a secure publishing story you need to follow one of the following patterns:
To use the Azure Pipeline relays agent:
To secure outbound traffic from your web app you need to use the regional VNet Integration feature. This feature enables you to make calls into your VNet and have all outbound traffic subject to Network Security Groups (NSGs) and Route Tables (UDRs). With NSGs you can restrict outbound traffic to address blocks of your choosing. With UDRs you can route traffic as you see fit. If you route the outbound traffic to an Azure Firewall device, you can restrict your outbound internet traffic to only the FQDN’s you want it to reach.
To secure your outbound traffic from your web app, enable VNet Integration. By default, your app outbound traffic will only be affected by NSGs and UDRs if you are going to a private address (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). To ensure that all of your outbound traffic is affected by the NSGs and UDRs on your integration subnet, set the application setting WEBSITE_VNET_ROUTE_ALL to 1.
Congratulations! In this article you learned how to secure your inbound and outbound networking traffic. You are now able to assemble App Service and Networking features to create a secure internet facing web application.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.