To have more control over accesses performed on SQL Azure Database, last month, Microsoft has publicly released the option to enable Virtual Network (vNet) Service Endpoints for SQL Database. This article will explain the working principle, with resulting benefits, and it will show its configuration.
Characteristics and principles of operation
The vNet Service Endpoints for the Azure SQL Database let you isolate the logical Microsoft SQL Servers in the cloud, guaranteeing access only from one or more subnets that are defined in their own Azure Virtual Network. This feature ensures that all traffic generated by own vNet to Azure SQL Database will always remain within the network backbone of Azure. This is a feature available in all regions of Azure and there are no additional costs for using it.
Figure 1 – Summary of architecture
On the firewall of the Azure SQL Database remains the ability to enable communication from the Azure services and to filter access based on a range of Public IP address.
Figure 2 – Azure SQL Server firewall settings
By enabling the setting 'Allow access to Azure services ' you are granted to access to SQL Server from all public IP address of Azure and from all Azure subnets, including those not of your own. Going to apply additional filters based on the public IP is difficult to manage and require the configuration of static public IP addresses on the Azure resources.
With the introduction of Virtual Network (vNet) Service Endpoints for SQL Server you can have more control over potential communications and less effort for resource management. The operating principle of the vNet Service Endpoints does not extend to the on-premises world even when there is connectivity with Azure (VPN or ExpressRoute), but to allow access from on-premises systems you must continue to use firewall rules to limit connectivity only to the public IP of your membership.
The Virtual Network (vNet) Service Endpoints are available, with the same principle of operation, also for Azure Storage and for Azure SQL Data Warehouse (currently in preview).
How to configure
Enabling vNet Service Endpoints require the activation on the subnet of the virtual network of Azure, from which you plan to connect to SQL Server, of the SQL Server Endpoint (Microsoft.SQL).
Figure 3 – Enabling SQL Server Service Endpoint on the subnet
Figure 4 – SQL Server Service Endpoint successfully enabled on the subnet
Next you must add on the SQL Database side the virtual network, with the Service Endpoint enabled , in the section Firewall and virtual networks.
Figure 5 – Added Virtual Network with Service Endpoints of SQL Server enabled
Each Virtual Network Rule is applied to Azure SQL Database server level and not at the individual database level.
This configuration means that by connecting to DB hosted by the Azure SQL Server from a machine attested on a vNet with Service Endpoints enabled, will be used as the source IP an address in the address space of the vNet. This aspect has to be considered, in existing configurations, to avoid that when you enable SQL Server Service Endpoint on the subnet, blocks access to SQL Server. For this purpose it is possible to avoid it allowing temporarily access with the setting "Allow access to Azure services", or by defining the vNet in firewall rule of SQL Server before enabling the Service Endpoint on the subnet. This requires using the flag IgnoreMissingServiceEndpoint or select the following flag present in the Azure portal:
Figure 6 – Added Virtual Network without Service Endpoints of SQL Server enabled
Conclusions
The Virtual Network (vNet) Service Endpoints are able to expand the virtual networks of Azure and its identity to certain Azure services, as Azure SQL Server, through a direct connection. This increases the security level of the services in the Microsoft cloud, optimize routing to access resources from the Azure vNet and lessens the management effort, all with a few easy steps.
