Every now and then I have a conversation with a client who is still reluctant to consider a cloud migration due to what they perceive as a decrease in their security posture. Once we start analyzing this position in detail though, we can see it does not hold under scrutiny. There is a perception that running older versions of Windows and SQL Server on your own data center or in a collocation environment is safer than migrating to a Database-as-a-Service offering in the cloud. But there is simply no comparison. So instead of continuing to rehash my arguments over and over, I decided to write this blog post to document my official position on this topic and hopefully either alleviate fears or confirm findings for other people. Note that when I say "Azure SQL Database" I'm referring to the family of products under this umbrella, whether it's a single database, a database pool or a Managed Instance. Now let's dive in!
Hosting in Azure
First, let's explore the idea of the security differences between a client's data center (which could be literally their basement) to a standard Azure data center. If you want to look at it from a legal perspective, you can find the list of all of Azure's certifications right HERE. It takes significant resources and legal expertise to certify in so many different regulatory standards managed by so many different governing bodies, an undertaking that would be impossible for any but the top 1% of enterprises out there.
Let's say you don't have to comply with any particular standard but just want to make sure your environment is safe. I have seen clients with a locked-down server room but very little in terms of controlling what their superuser employees are doing. In Azure, you can set up all sorts of auditing policies so that every single change or action against the system is recorded or outright prevented. Microsoft has also added services such as Azure Bastion that provide secure Linux and Windows bastion hosts so that administrators that do require a remote connection into a production system can do it in the most secure way possible.
And let's not even get started on the topic of physical security. If you think it would be easy to simply walk into an Azure region and walk out with a particular piece of data of interest, then I suggest you watch this video just to get an idea of the scope and size of each one of these data centers.
Now, of course, cloud security is a SHARED responsibility so you need to do your part in protecting the data as well and not expect Azure to do everything for you. For this, our next section comes into play.
Broad Feature Offering
Now let's move on to the product itself, either SQL Server or Azure SQL Database. First, starting from SQL Server 2016 SP1, Microsoft made a huge change in licensing, pushing lots of features from Enterprise to Standard edition, including many security-related ones. Transparent Database Encryption (TDE), the ability to encrypt the data files at rest, was one of the few that remained in Enterprise edition, but not anymore. Starting with SQL Server 2019, TDE is also available on Standard edition, bringing both editions to feature parity in terms of security. 
And let's look at all the investments that Microsoft has done in the last few releases:
- Row Level Security - for in-engine support of RLS (usually had to be implemented through views or other such methods).
- AlwaysEncrypted - full encryption on the database server with only end-user access to decryption keys. Upgraded to support complex calculations through the use of secure enclaves.
- Dynamic Data Masking - in-database support for masking sensitive data.
- Data classification and auditing - set of tools and reports for discovering and tagging sensitive data.
And when you move to the cloud, there is no feature difference, all of these features are available on Azure SQL database.
Cloud-Only Advantages
On top of the features that are included in the 25+ years of code in the SQL Server database engine, the cloud also offers some extra advantages over running SQL Server on-premises. First, instead of running SQL Server inside a Virtual Machine, you can run it as one of the Azure SQL Database offering models. Doing this, you are greatly reducing the surface area of attack for your databases. Say you had some ransomware infect a Virtual Machine, encrypt your data drive, then transmit itself over the network and continue doing damage to other machines including your database servers. Now, replay this scenario but using Azure SQL Database instead. The only port available to communicate to the database is the TDS protocol one, no other OS ports are exposed, and there are no network shares. There would just not be any way the ransomware could find a way to execute inside the SQL process and your infection would not impact the most important asset: your data. Even on the most catastrophic scenario where a ransomware was custom built to use a privileged user's account, connect to the database and then encrypt it or wipe it out, all the services offer point-in-time restore and you could easily, in minutes, roll back to the pre-attack version. On top of this, Microsoft also offers "Advanced Threat Protection", a surveillance service that is constantly monitoring your databases for anomalous connection attempts and access patterns, providing real-time alerts to an operator.
By using any of these Database-as-a-Service offerings, you have the security of hosting inside Azure, the rich feature set from SQL Server and you also get the added advantages I mentioned above. I don't believe this can be easily matched on-premises.
