Microsoft FastTrack for Azure
This article describes simple steps to secure your application by isolating the PaaS services with virtual networks and making sure the communication between them is private.
It also addresses:
1. How to protect your web application from known exploits and vulnerabilities
2. How to securely build and deploy inside a virtual network.
Only network related concepts are covered, all the best practices to secure your PaaS deployments being available here.
A common scenario is when you have an application hosted in Azure and running on PaaS services such as App Service Web Apps with SQL Databases, Storage Account, Redis Cache, etc. PaaS services are easy to use, they don’t' require a lot of management and often help developers achieve the desired outcome very fast.
However, some important questions that you need to ask in this scenario are:
- How secure is my application?
- Who can access each individual resource?
- Do I need to isolate my resources?
- Should the traffic between the resources be public over the internet or private?
- How are my resources authenticating to one another?
- What if someone will attack my publicly accessible resource (such as the web app or the database)?
The base scenario used as an example:
- Web tier: Web application hosted on App Service Web App in an App Service Plan compute tier
- Data tier: The application gets data stored in Azure SQL Database and Azure Blob Storage
- Access tier: Globally distributed users access the application via web browser over the public internet
- Management tier: Developers need to access the application for updates and management
In this scenario, all the resources have publicly accessible fully qualified domain names (FQDN), which are the hostnames. This means that every FQDN is resolved to a dynamically assigned Public IP, that is discoverable by anyone on the internet. To see the Public IP that an FQDN resolves to, it's enough to ping the hostname.
>ping [WEBAPP_NAME].azurewebsites.net
Pinging [INSTANCE].[REGION].cloudapp.azure.com [PUBLIC_IP] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for [PUBLIC IP]:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
As best practice, you should always protect resources from unauthorized access or attack by applying controls to network traffic and building your application with the Zero Trust principles in mind.
STEP 1. Keep the traffic between resources private
If we think about how security breaches occur, almost every time it happens to services that are exposed to the public internet. It's safe to say that reducing the Internet exposure reduces the risk of a breach, although it doesn't eliminate it completely. Resources that are exposed unnecessarily to the internet increase the number of ways that attackers can gain access to your application or just bring it down and make it unavailable. By reassuring that the resources are private and isolated, you make it harder and harder for attackers to get in.
A Virtual Network (VNet) is a logical isolation of the resources. VNet enables many types of Azure resources, such as Azure Virtual Machines (VM), to securely communicate with each other, the internet, and on-premises networks. Out of the box, the IaaS resources are isolated (VMs), while the PaaS resources are not isolated in virtual networks, but this can be an additional feature specific to each resource.
App Service VNet Integration
With Azure Virtual Networks, you can place many of your Azure resources in a non-internet-routable network.
The App Service virtual network integration feature enables your apps to access resources in or through a virtual network.
Keep in mind that virtual network integration doesn't enable your apps to be accessed privately.
App Service has two variations:
- The dedicated compute pricing tiers, which include the Basic, Standard, Premium, Premium v2, and Premium v3.
- The App Service Environment (ASE), which deploys directly into your virtual network with dedicated supporting infrastructure and is using the Isolated and Isolated v2 pricing tiers.
The virtual network integration feature is used in Azure App Service dedicated compute pricing tiers. If your app is in an App Service Environment, it's already in a virtual network and doesn't require use of the VNet integration feature to reach resources in the same virtual network.
For the example mentioned above, it's recommended to use a the Regional VNet Integration feature, so that you can isolate your Web App and make it access the other resources privately from inside a virtual network. The steps for enabling Regional VNet Integration on a Web App can be found here.
Once you integrate the Web App inside of a VNet, it means that from now on, the Web App will be able to access any internal resources from within the VNet or any other peered VNets.
So why do we need this? What does the Web App need to access privately? Up until now, the Web App was getting the data by accessing the SQL database and the Storage Account over a public internet connection. A best practice is to ensure that the communication between the Web App and the backend resources is private and the traffic only traverses the virtual network and nothing outside of it.
Private Endpoint for SQL Database and for Azure Storage
A private endpoint is a network interface that uses a private IP address from your virtual network. This network interface connects you privately and securely to a service that's powered by Azure Private Link. By enabling a private endpoint, you're bringing the service into your virtual network.
Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over a private endpoint in your virtual network.
By using private endpoints with private link secure connectivity, the PaaS services from our architecture (Azure SQL Database and the Azure Storage Account) can be securely accessed by the Web App. Therefore, we disable the public endpoint on the Storage account that was accessible from the internet. Check these articles for more details on using private endpoints for Azure Storage and web app private connectivity to Azure SQL Database.
A recommendation is to disable all public access to your logical database server and allow connections only from your virtual network. This can be done from the SQL server Networking configuration, by setting the Public network access to Disable.
Also, it is recommended to secure your storage account to only accept connections from your VNet by configuring the storage firewall to deny access through its public endpoint by default. You don't need a firewall rule to allow traffic from a VNet that has a private endpoint, since the storage firewall only controls access through the public endpoint. Private endpoints instead rely on the consent flow for granting subnets access to the storage service.
STEP 2. Inspect the incoming traffic for malicious requests
Whether you’re delivering content and files or building global apps and APIs, Azure Front Door can help you deliver higher availability, lower latency, greater scale, and more secure experiences to your users wherever they are.
Azure Front Door is Microsoft’s modern cloud Content Delivery Network (CDN) that provides fast, reliable, and secure access between your users and your applications’ static and dynamic web content across the globe. Azure Front Door delivers your content using the Microsoft’s global edge network with hundreds of global and local Point-of-Presence distributed around the world close to both your enterprise and consumer end users.
In the above scenario, the users are accessing the web application from all over the world via a web browser. However, there is no mechanism to verify the incoming requests and protect the application against common exploits and vulnerabilities. One solution for this can be to use the Azure Web Application Firewall (WAF) on Azure Front Door. WAF prevents malicious attacks close to the attack sources, before they enter your virtual network. You get global protection at scale without sacrificing performance.
By using Azure Front Door and WAF, not only you accelerate and deliver your app and content globally, but also intelligently secure your digital estate against known and new threats with intelligent security that embrace a Zero Trust framework.
If you're not sure whether you need to use Azure Front Door or another type of load balancer, please consult the decision tree for load balancing in Azure.
Now that Azure Front Door is in place, it should be the only point of entry for the users when accessing the web app. This means that the situation when anyone can just bypass the Azure Front Door and access publicly the web app needs to be addressed. You can restrict the access to your web app so only requests coming from the Azure Front Door will be allowed and any other requests will be blocked. You can set up Azure App Service access restrictions to permit access only from the Azure Front Door.
STEP 3. Securely build and deploy the code to the application
If you need to allow your developers to work and access securely the application, there are a few ways to do this:
- Add the developers IP addresses in App Service Access Restrictions, so that the developers can still access the web app over the public FQDN of the web app. Block everything else.
- Use a Private Endpoint and Private Link connectivity to bring your web app also inside the virtual network... With this option, the inbound access from the internet to your web app will be blocked by default, so you don't need Access Restrictions anymore.
Remember that virtual network integration doesn't enable your apps to be accessed privately, so you need to use Private Endpoint and Private Link for secure access to the web apps. Once the web app can be accessed from inside the virtual network, you can have an Azure DevOps agent running on a VMSS in Azure from which developers will be able to build and deploy the application from a VM inside the same virtual network.
For accessing the Azure DevOps agent, you can do the following:
- Create a secure cross-premises connectivity between the company network and the virtual network in Azure, so that everyone connected to the company network will be able to access the resources in Azure that are isolated. This will be a Site-to-Site VPN connection.
- Create a secure connection to your virtual network from an individual client computer, by using a Point-to-Site (P2S) VPN gateway connection.
- Attach a Public IP to the VM and simply RDP/SSH on the Public IP. This is not recommended, since it still uses a Public IP, which can be accessed and attacked by anyone. If you choose this option, consider protecting your Public IP with the Azure DDoS Protection.
STEP 4. Don't stop at network isolation, consider other best practices to make your application as secure as possible
- Securely connect to Azure services and databases from Azure App Service
- Direct connection from App Service managed identity
- Connect using Key Vault secrets from App Service managed identity
- Connect with app settings
- Check all the security recommendations for Azure App Service
- Go through the Azure database security checklist
Not sure how to start? Check out these relevant Azure Samples:
- Web app private link with Azure SQL DB and storage - Code Samples | Microsoft Learn
- Deploy an app service with regional VNet integration - Code Samples | Microsoft Learn
- How to configure an Azure Web App to call Azure Cache for Redis and Azure SQL Database via Private E...
- Azure-Samples/app-service-networking-samples: This repo contains a sample application and demos for ...
FastTrack for Azure: Move to Azure efficiently with customized guidance from Azure engineering. FastTrack for Azure – Benefits and FAQ | Microsoft Azure