Migrating SQL Server to the Cloud – SQL Server Cloud Security
This is the fourth in a series of blog posts about SQL Server and the cloud (here you can read one, two and three). In this post we will take a look at how connectivity to a cloud based SQL Server is achieved and we’ll also touch on everyone’s favorite topic: Security!
Connecting to a cloud based SQL Server isn’t much different that connecting to an instance running in your local data center – you just need to enter the server name (or IP address) and a port number.
However, the fact that the SQL Server is running in the cloud means you need to tighten down access to prevent unauthorized connections. When starting out with cloud based instances this was a concern of mine as networks can be unbelievable complicated to understand. Fortunately the cloud makes network configuration incredibly simple. So simple that even I was able to easily master it!
Here is a brief overview of each cloud providers approach to network connectivity:
The preferred method of launching a VM in AWS is to use an Amazon VPC (Virtual Private Cloud). This allows you to define a “virtual network” in your own logically isolated area within the AWS cloud, which closely resembles a traditional network that you might operate in your own data center.
AWS uses security groups to control who can access your instances. This enables you to specify the protocols, ports, and source IP ranges that are allowed to reach your instances and you can create multiple security groups and assign different rules to each group. Using security groups you can easily control who accesses the SQL Server without having any prior knowledge of how to configure networks.
Once configured you can access your database via Windows Authentication or SQL Server authentication using either the DNS entry or IP address and port number.
To combat the issue of the IP address changing each time the VM restarts you can assign an elastic IP address which is just a fancy way of saying “static IP address”.
GOOGLE CLOUD PLATFORM
Google defines everything at the “project” level and every VM is provided with a default network configured with preset settings and firewall rules which restrict access.
You can either customize the default network for your purposes or create an additional network with your own rules to allow user connectivity. Once configured you can connect to your SQL Server using the usual methods.
Static IP addresses are achieved by “IP forwarding” so you can send traffic from your VM to a specific IP address.
Similarly to AWS, Azure allows you to create an Azure Virtual Network in which you can define Network Security Groups to control IP range access to the instance.
Additionally as part of the Azure instance launch and SQL Server installation process you configure the port(s) that the SQL Server will listen on and you also define what connections are allowed, for example public (anyone on the Internet), domain (when someone connects from your corporate domain using Windows Authentication) or private (a connection from a defined private network using SQL Server authentication).
By defining and using a DNS name to connect to the Azure instance you will avoid any issues with IP address changes following Azure instance restarts, but to get a static IP address you can allocate “reserved IP addresses” to your instance.
Another of the hot topics around cloud based services is security. Now if you are like me then you always relish a visit from your friendly ISO to discuss the latest security protocol, patch or upgrade (apologies for the sarcasm). However, moving your services into the cloud actually makes your job easier as the cloud vendors take security VERY seriously and they adhere to every single security protocol you have ever heard of plus many that you haven’t.
Cloud providers ensure that protocols, patches and upgrades take place in a timely manner so you are always protected. So there is an argument that if you move your SQL Servers into the cloud using best practices they will be MORE secure than where they currently reside.
Next week we’ll take a look at the actual migration process to get your databases into the cloud.
To streamline your migration to AWS, just email me at email@example.com.