Having Microsoft Azure host SQL Server databases on their servers is very cost-effective and efficient. Within minutes, one can have a SQL Server database hosted in the cloud and available to applications on the cloud or on premise.
As with all cloud resources, and especially databases, security is a huge concern. Fortunately, SQL Azure includes features to restrict what can connect to your database server but you need to know how to use them and realize that the default settings do not protect you best.
From the Azure portal, choose "SQL servers" from the left column of resources, and select your database. You'll get the overview.
On the left column under Security, select "Firewalls and virtual networks":
These settings let you restrict the IP addresses that can communicate with your server. If a request comes from an IP address that's not on the list, the commands are ignored. This is an important feature for cloud solutions so that only permitted sources are allowed to get data from your server and databases.
When unauthorized connection tries to open the database, it triggers an error like this:
Cannot open server 'ServerName' requested by the login. Client with IP address '18.104.22.168'. is not allowed to access the server. To enable access, use the Windows Azure Management Portal or run sp_set_firewall_rule on the master database to create a firewall rule for this IP address or address range. It may take up to five minutes for this change to take effect.
On the right pane, you can set the range of IP addresses that you'll allow to contact this server. You can specify individual IP Addresses or a range of IP Addresses and provide a friendly name to remember it:
You could specify a range of all IP addresses, but that would defeat the purpose of the firewall. You should restrict the IP Addresses to just the sources that are authorized to connect to your database. That doesn't eliminate all security problems but is an important step for any cloud database.
In addition to specific IP Addresses, there's a section below this to specify Virtual Networks. If your organization is using a VPN with a fixed IP address, you can just add that to the list of IP Addresses but a VPN in the cloud can be assigned here and if its IP Address changes, the connection remains authorized.
Firewall rules can also be managed through Transact-SQL (T-SQL) at the server's Master database level:
You can also set IP addresses in each database using Transact-SQL:
A database with its own firewall settings can be moved to another server and allow the same connectivity regardless of the server level rules, but I find this counter-intuitive.
I assumed the server rules would be checked first to restrict the IP Addresses that could contact any of its databases, but the opposite is true. The database firewall settings are checked and if the IP address fails, the server level rules are checked.
This also means that if you inherit a SQL Server database, you need to check its firewall settings to make sure they don't leave a security hole when you host it on a new server.
For more details, visit this Microsoft article: Azure SQL Database and SQL Data Warehouse firewall rules
So what IP addresses do you include?
If you need to connect to the database outside of Azure, you'll need to include those IP addresses. For instance, if you are developing a web application on your PC, your local IP Address needs to be included so that you can run your application locally and get to the data. Ideally, your organization has a fixed IP address you can use or a VPN that you connect to when working remotely. Alternatively, you may need to add every IP Address that you use during development such as your home connection.
Similarly, if you or your users need to connect to the data directly via Microsoft Access or Excel, their IP Addresses need to be included or if your organization has a VPN, use that IP address. If your users are travelling around and trying to connect from random airports and hotels, that will be very challenging if you don't have a VPN to provide a secure connection.
By default, all Azure resources can connect to your server and databases hosted on Azure:
This is helpful if you are connecting to your database from web sites hosted on Azure Virtual Machines, App Service Plans, etc. It eliminates the need to manually specify the IP Address of each resource in your list.
If you "Allow access to Azure Services" set to On, you create a huge security hole for your server and every database in it.
Not only can all your resources connect to your databases, Any Azure resource from any organization can connect to your database.
This setting is NOT restricted to the Azure resources in your subscription. It'd be nice to restrict permissions to the current subscription or list of subscriptions but that's not possible. It's everything on all of Microsoft Azure or you need to specify each IP address.
Set the permissions to OFF to disallow all Azure services to connect to your SQL server:
To avoid the ability of rogue Azure resources from breaching your database security, you need to manually specify the IP Address of every resource that may connect to your server and databases. This can be a real pain.
For instance, if you have a web application connecting to the SQL Server database from an App Service Plan, you need to open that plan, choose the particular service, and in the Settings section, select Properties:
From there, you'd copy the IP Addresses from the two Outbound IP Address lists and add it to the firewall of your server.
Have any questions, feedback or suggestions? Visit our Blog and leave us a comment!
When and How to Upsize Access to SQL Server
Importing Access Tables into SQL Server
Microsoft Access within an Organization's Database Strategy
What it Means to Information Workers
Link Microsoft Access to SQL Azure Databases
Deploy MS Access DBs linked to SQL Azure
Monitor SQL Server Usage and DTU Limits on Azure
Convert Azure SQL Server to Elastic Pools
Database Backup and Restore on Network
SQL Server Express Editions and Downloads
SQL Server Express Automated Backups
Migrate Your Data Tier to SQL Server: Strategies for Survival
Microsoft Access Database and Migration Challenges
Are we there yet? Successfully navigating the bumpy road from Access to SQL Server
Microsoft SQL Server Consulting Services
Visual Studio .NET programmers for web development
General Microsoft Access consulting services
Microsoft Access Developer Help Center
MS Access Developer Programming