How to improve communication security between App Service and Azure SQL Database

Posted by: Vladimir Stefanovic August 17, 2020

Category: Topic: Microsoft Azure

One of the essential aspects of application design is security. Without adequate security at all layers of infrastructure, an application could be exposed, and a breach potential is much higher. But, if we talk about Platform-as-a-Service services in Azure, many people think that their infrastructures are secured by design. Moreover, they are sure that Azure is responsible for handling all security features. Unfortunately, that is not a correct statement, and we have to implement or enable additional security features to improve security at all.

If we have Azure App Service as a frontend layer and Azure SQL as a database layer, one of the implementations should be Private Link. With the Private Link implemented, App Service and Azure SQL will use the virtual network for the communication. Azure App Service, as an additional option, can be integrated with a specific virtual network. On the other hand, a private link endpoint could be implemented on the Azure SQL Server side. So, let’s take a look at how to configure this for the App Service and Azure SQL Server.

Initial App Service/Azure SQL configuration

In our demo environment, App Service hosts a simple .NET Core application and has a connection with Azure SQL Database. At the same time, Azure SQL Server has configured firewall configuration „Allow Azure services and resources to access this server“ on YES, which allows our App Service to communicate with Azure SQL Server. Unfortunately, although that feature enables our Azure SQL Server to communicate with App Service, which is an Azure Service, that firewall configuration poses a significant security risk and leaves the SQL Server vulnerable. That configuration allows any traffic from resources/services hosted in Azure (not just our Azure subscription) to access the database.

One of the possible solutions to minimize risk is implementing the aforementioned Private Link on Azure SQL Server side and the virtual network integration on the App Service side. Before we start with the implementation, we can check how our App Server resolves the FQDN of our Azure SQL Server. To complete this check, we need to open Console access of the App Service and run command nameresolver <azure-sql-server-fqdn>.

Once we confirm that the App Service is resolving the Azure SQL Server FQDN with the public IP, we can start with the implementation of changes.

Deploying Azure SQL Server private link

The first step in that implementation is configuring a private endpoint for Azure SQL. Once we open the desired Azure SQL Server in Azure, we can find that Private endpoint connections under the Security in the left pane.

When we start with creating a private endpoint, we just need to follow the wizard. We have to select a resource group, name, location, what resource is affected by this private link, and what virtual network will be the host of the private endpoint. Enabling a private endpoint gives us the possibility to integrate Private DNS Zones with this feature, which is recommended. Once the deployment is completed, we can see that our Azure SQL Server now has a private IP address.

Enabling App Service vNet integration

The next step is enabling the virtual network integration in our App Service. Once we open the desired App Service, in the left pane under the settings, we can find Networking.

When we open the Networking section, the first option to configure is VNet Integration. The process is straightforward and just need to select an appropriate virtual network and empty subnet. Then, we just need to add two parameters more in the App Service configuration to have a fully functional App Service. By default, App Service routes only RFC1918 traffic into your VNet and cannot work with the Azure DNS Private Zones. If we want to route all of your outbound traffic into your VNet and use the Azure DNS Private Zones, we need to add the following settings in App Service configuration:

Final checks

Once we have implemented those changes, we can disable public access to our Azure SQL Server, by setting Deny public network access on YES and Allow Azure services and resources to access this server to NO. Now, we can run the command nameresolver <azure-sql-server-fqdn> from App Service console again, to see what result will be:

As we can see, our App Service now communicates with the Azure SQL Server using the private IP address, assigned to the Azure SQL Server as a private endpoint. Along with that, public access is disabled, and we can say that communication between these services is secure.

Want to improve your cloud security?

Get in touch with our experts. The consultation is free.


Keep reading

How to Migrate Your Application from Monolith to Microservices


According to a 2020 O’Reilly report on microservices adoption, 77% of businesses have already adopted microservices, while 92% of them state they are experiencing success after migrating monolith to microservices. The trend to en-masse start using microservices application architecture comes as no surprise considering the multiple benefits that the microservices architecture provides, including: Improved resilience […]

read more

What is Cloud Bursting and Does Your Business Need it?


Back in 2014, NASA launched a satellite called OCO-2 (Orbiting Carbon Observatory 2) to gain more insight into the Earth’s carbon uptake. Two years later, they had petabytes of gathered data that needed to be processed which would have taken over 3 months and cost about $200,000 if they had used on-premise data centers for […]

read more

How Managed Cloud & Open Source Solutions Fuel Business Growth


With the modern business landscape becoming more and more saturated and competitive in recent years, companies worldwide face an ongoing challenge of emerging through the noise and initiating growth. The resources are often suboptimal, which can make the process of developing a cost-effective and sustainable business strategy an insurmountable problem for many companies.  Luckily, with […]

read more