共用方式為

Secure your on-premises network outbound connection to Azure SQL Database by locking down target IP addresses

  • 發行項

Reviewed by: Dimitri Furman, John Hoang, Mike Weiner, Rajesh Setlem

Most people familiar with Azure SQL DB (aka SQL Database) are aware of the firewall setting requirements of SQL DB, which are very important to lock down connections to SQL DB on Azure. Details are documented here. The firewall setting helps restrict inbound connections to clients with specific IP addresses. Note that this refers to the firewall on the Azure SQL DB side. But when the SQL client is running on-premises behind internet gateway/proxy server, the firewall of the gateway/proxy server needs to be configured as well, to allow outbound connections to Azure. Other than opening TCP port 1433, which is the port SQL DB listens on, customers may also limit the IP addresses of target SQL DB that are allowed for outbound connections. This is important from security perspective, since it blocks unwanted network traffic and limits the extent of damage that a potential hacker/malware could do to copy confidential data out of the on-premises network. So how do you know your intended target Azure SQL DB IP addresses for outbound connection?

I had a customer using a simple approach to get his SQL DB IP address. Let me explain with an example. When you spin up a SQL database on Azure, it's always associated with a logical SQL Server, which has a DNS name like this (shown on Azure portal SQL DB overview blade):

It's easy to look up its IP address by ping.

The customer got his SQL DB IP address and configured his on-premises network firewall to allow outbound connection only to the IP address for his SQL client application. And it worked! But only until one day that IP address changed without notice. What happened?

SQL DB actually has a fixed set of public gateway IP addresses. These IP addresses have been published in this article on SQL DB connectivity (It's also a very good read for you to understand the connectivity architecture of Azure SQL DB). Note that for each region, there could be up to 2 IP addresses, which provide enhanced high availability for the SQL DB gateway. The aforementioned customer had connection problem in the end because when the gateway failover occurred, its IP address switched to the secondary. So it's very important to configure your on-premises firewall to allow outbound connections to both gateway IP addresses of each region. And here is the important part: these IP addresses won't change. But equally important note: the regions with only primary IP address today eventually will have secondary IP address as well. For future updates on these secondary IPs please refer to this article.

If your on-premises application uses other Azure services besides SQL DB (e.g., storage, compute), and you desire to control outbound connections to all IP addresses of each Azure region, you may download the current IP addresses here. Note:

  1. It includes SQL DB IP addresses as mentioned above.
  2. It's updated on a weekly basis so you need to update your on-premises firewall rules accordingly (unlike SQL DB, other Azure service IP addresses might change over time)

Summary: to help secure your on-premises network environment, it's a best practice to configure your on-premises firewall and allow outbound connections on port 1433 only to your target SQL DB IP addresses listed here. To allow outbound connections to other Azure services besides SQL DB, the IP ranges can be downloaded here, which is updated every week.