Share via

Azure SQL Database: Security Guidelines

  • Article

Overview

Microsoft Azure SQL Database is a cloud database service by Microsoft. Azure SQL Database provides web-facing database functionality as a utility service. Cloud-based database solutions can provide many benefits, including rapid provisioning, cost-effective scalability, high availability, and reduced management overhead. This document provides an overview of security guidelines for customers connecting to SQL Database, and building secure applications on SQL Database.

The Tabular Data Stream (TDS) protocol is used by all SQL Server and SQL Database tools and client libraries to connect to the servers. The SQL Database service is only accessible through the default port of TCP/1433 used by the TDS protocol. SQL Database have two types of access control: SQL authentication and server-side firewall. In addition, you must also configure your client-side firewall.

Note

If you wish to contribute to this page, use the Edit tab at the top (sign-in required). If you wish to provide feedback for this documentation please either send e-mail to azuredocs@microsoft.com or use the Comment field at the bottom of this page (sign-in required).

Client-side Firewall

Network firewall and other security devices may prevent computers on the customer networks from establishing outbound connection to SQL Database. Customers must configure their environment to allow outbound TCP connections over port TCP/1433 to enable applications and tools to connect to SQL Database.

Some networks allow all return traffic for any connection initiated internally, but other more restrictive networks also restrict return traffic to explicit access control lists. Customers may also need to explicitly allow return traffic from SQL Database IPs back into their network, depending on how strict their policies are.  In other words, if a customer allows outbound TCP/1433 traffic to SQL Database IPs, they also need to allow the return traffic coming from SQL Database IPs (source port of TCP/1433) back into their network.  

It may be more convenient for customers to allow TCP/1433 connections to the range of Microsoft’s public network addresses instead of a specific SQL Database location. This will allow for greater flexibility; as SQL Database adds more locations, the need to revisit customer access control lists will be reduced.

For example, the TDS endpoint for the SQL Database North Central US data center is data.ch1-1.database.windows.net, with an IP address of 207.46.203.22. Performing a whois lookup reveals full network ID 207.46.0.0/16 belonging to MICROSOFT-GLOBAL-NET

The following is an example ACL setting to allow connections to the entire range of possible IP addresses for Microsoft SQL Database Service.

Inbound ACL (outgoing traffic): permit tcp any gt 1023 host <SQL Database IP> 1433 Outbound ACL (return traffic): permit tcp host <SQL Database IP> 1433 any gt 1023 established

The use of the “established” tag for outbound ACLs, such as in the examples below, will return traffic for customer sites to connections established within the customer site. In other words, traffic will not be allowed unless the connections are initiated within the customer site.

Important: Inbound connections are not required or recommended.

Proxy servers may need to be adjusted to allow the outbound TDS protocol over port 1433. Client-side proxy software such as Microsoft ISA client may be needed to allow client computers to use proxy servers for outbound connections.

Optional: If you have on-premises SQL Servers that need to communicate with SQL Database for data synchronization or other reasons you must ensure that your servers have an internet routable IPs.

Server-side Firewall

Use Azure Platform Management Portal to configure the SQL Database firewall settings to allow connections from your computer(s) and/or Azure. More details on configuring the firewall can be found here – How to configure firewall and Azure SQL Database firewall.

Always use the loginname@Servername format for the login since certain tools implement TDS differently. For example, if your server name is mv2abek9r7.database.windows.net and your administrator login is testsa, use testsa@mv2abek9r7 as the login.

SQL Authentication

SQL Database supports only SQL Server Authentication. Since it runs in the cloud it would have no way of knowing anything about a user's Windows Authentication (integrated security) so it cannot be supported. Users must provide credentials (login and password) every time they connect to SQL Database.

Create appropriate logins on your SQL Database server. After the SQL Database server has been provisioned, create the administrator user that has administrator privileges on the server, connect to your master database on your SQL Database server via SQL Server Management Studio R2, and use the CREATE LOGIN scripts to create users and roles. More detailed information on managing logins is available at Managing databases and logins in Azure SQL Database

Developers and database users can now use the logins created above to connect to SQL Database.

Other Guidelines

  • When connecting to SQL Database, use the most current version of tools and libraries for best experience.
  • Configure your firewall to allow connections only to specific IP addresses.
  • Prevent SQL injection vulnerabilities by using parametrized queries.
  • SQL Database server is just a logical grouping of databases. It is not a physical SQL Server. Hence creating multiple servers will not provide any performance benefit. You can create multiple servers if you want to group sets of databases into logical unit(s) or if you want to have a separate billing for certain database(s).

Community Resources

Other Languages

This article is also available in other languages, including Russian.

Рекомендации по безопасности для Azure SQL Database

Credits

The author of the original information contained in this article is Dinakar Nethi.