The easiest way to enable access to an Azure SQL Server is to set the “Allow Azure services and resources to access this server” switch to “yes”. But if the Allow Azure services and resources to access this server check box is set to Yes, all Azure resources from all tents, all subscriptions, all customers in Azure have network access to your SQL server.
That is very uncertain!
To secure access to the SQL server, “Allow Azure services and resources to access this server” should always be set to No. The virtual network rules can then be used to specifically provide access to individual subnets in your own Azure tenant.
For this to work, so-called service endpoints must be created in the target Vnet Service endpoints to ensure that traffic in Azure is routed to access Azure resources only through the Azure backbone, not over the Internet.
Creating a service endpoint is quite easy.https:
//docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview
After the service endpoint is created, a Vnet rule can be created in the Azure SQL Firewall for the target network.
Now the target can also be secured with a network security group. The destination no longer needs access to the Internet because a service endpoint has been set up. In the screenshot, there is another rule, the top rule for RDP, because I created the example with a VM. The VM does not have access to the Internet, but the SQL server can be accessed through the service endpoint.
This means that the SQL server is still published to the Internet, but the firewall prevents access. A “private endpoint” is required to disable the SQL server’s public endpoint and expose it only in your own Azure tenant.
I explained the configuration with a private endpoint in another article .