An organization employing over eight thousand employees within the public sector has been migrating their database systems in a consistent manner to Microsoft SQL Server. The reasoning behind this migration is two-fold: firstly, the organization is moving all resources to Microsoft Azure and, as such, expect improved support for the product. Secondly, the organization wishes to leverage all which the cloud can provide, which means moving to PaaS and eventually managed services; these offerings are not available with systems such as MySQL and PostgreSQL, and Oracle in the Azure cloud space is not cost efficient. However the movement to a new database platform has risks; I will be discussing some of the risks related to the security of Microsoft SQL Server and ways to prevent or mitigate such risks.
Artemiou (2016) provides a good list for starting points for securing your SQL server. Several items do stand out, but in particular I will be discussing two things: the patching of SQL Server and setting up database encryption.
Patching is important for both the operating system (either Windows or Linux) as well as for SQL Server itself. Netwrix (n.d.) points out that hackers are continually finding new ways to infiltrate SQL server; and as soon as Microsoft finds them, they implement fixes which are then meant to be applied by the DBA. Coeo (n.d.) also agrees, pointing out that attacks such as the “speculative execution side-channel attack” was discovered and patched by Microsoft, leaving consumers of SQL safe from such attacks.
But, patching a SQL server is not easy; these servers are typically mission critical and cannot go down. Additionally, the underlying operating systems can’t go down either. So, what’s a DBA to do to keep their systems secure? One method pointed out by Tintri (n.d.): AlwaysOn.
AlwaysOn is a SQL tool whereby a load balancer sits in front of multiple, clustered SQL servers; the balancer talks to the listener, which is the device which determines which SQL server is primary and which is secondary (“Business continuity and database recovery “, 2017). The load balancer directs the consumer to the primary database server, leaving the secondary servers to stay just that: secondary. Should a failover occur from the primary to a secondary, the load balancer will send traffic to the new primary. Therefore patching, according to Tintri (n.d.) is as simple as patching your secondary servers, failing over, and then patching your previous primary. Of course, they caution that testing be performed ahead of time in a lower environment, lest you break your applications.

Microsoft MSSQL AlwaysOn Cluster Diagram.
AlwaysOn helps to protect the organization from attacks by allowing DBAs to patch systems which require a continuous uptime, such as database systems. For this large organization, downtime of database systems is unacceptable, but security must be a priority. According to Microsoft (“Business continuity and database recovery “, 2017), AlwaysOn allows for the ability to switch database servers, patch those which are not in active use, and then fail back if desired; this allows for patching “offline” servers and keeping them secure.
The second item I want to talk about is database encryption. Specifically, I want to talk about disk vs. file encryption. Bitlocker is a tool which allows for the encryption of entire disks (Bitlocker, 2017). In order to decrypt a drive, such as one which holds database files, the drive must be “unlocked” using a passphrase or even a certificate. If your BIOS isn’t TPM compliant, you can still use Bitlocker; Bitlocker will simply ask you to store a startup key on a drive which is not attached to the system, such as a USB drive.
Bitlocker encrypts entire drives, including database files, but once the drive is unlocked, a hacker can grab your database files from right under your nose. (Bitlocker, 2017). Bitlocked drives must be unlocked before they are usable, therefore your databases in the wild are not protected from something as simple as a file copy. This is where Microsoft Transparent Data Encryption (TDE) comes into play.
According to Microsoft documentation, transparent data encryption encrypts SQL server data and log files, without any need for “unlocking” except when transactions occur (Transparent Data Encryption, 2019). The benefit of TDE is that the files are never truly unlocked; therefore, a file copy by a malicious user on your network yields them nothing but an encrypted, unusable file. With Bitlocker, this is not the case; the copied file would be unencrypted (Bitlocker, 2017).
TDE works with not only SQL itself, but with the underlying Window’s Data Protection API to create service keys; therefore, SQL is not reinventing any wheels (Transparent Data Encryption, 2019). Encrypting a database is also very straightforward. Using only T-SQL, you create a master key, create an encryption key, and then issue an “ALTER” statement against the database to tell it to encrypt using the key which you just created. Of particular note is that the master key is only used to encrypt the keys you create yourself so that they are not stored in plain text in your database, so your database server can have one and only one master key.
There are several other notes I would like to discuss when using TDE. First, that key you created to encrypt your database? Back. It. Up. If you lose your database server and have to restore to a new SQL instance, you will have to import that key for your database backups to be usable (Transparent Database Encryption, 2019). I’ve seen all too often the sad face of a DBA who can’t find their encryption keys. Second, keep your basic SQL skillset up to snuff: remember where the results of table joins and like go? Tempdb (Tempdb Database, 2019). How secure would your data be if they were highly protected in the data files, but then open to the world in tempdb? A hacker could just keep making copies of your tempdb until they got the information needed. So, to protect against this, if ANY database on your server is leveraging TDE, tempdb is automatically encrypted and you cannot change this (Transparent Database Encryption, 2019; Tempdb Database, 2019). Personally I find this to be a pretty nice touch.
So that sums up what I wanted to discuss re: SQL server and security. For my next article I’ll discuss Microsoft SQL Server Always Encrypted, but that’s beyond the scope of this article as it is much, much more complicated, but in my humble opinion, much, much more interesting. So thank you for reading, and as always, post comments and I’ll do my best to answer any questions which you may have. I’ve been doing DBA work for around thirty years now, so I’ll do my best to answer as thoroughly as possible as well as give you links to Microsoft documentation.
Regards and best wishes
References
Artemiou, A. (2016). Top 10 security considerations for your SQL Server instances. Retrieved from https://www.sqlshack.com/top-10-security-considerations-sql-server-instances/
Bitlocker (2018). Retrieved from https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-overview
Coeo. (2018). You must upgrade SQL Server to stay secure. Retrieved from https://blog.coeo.com/you-must-upgrade-sql-server-to-stay-secure
Business continuity and database recovery – SQL Server. (2017). Retrieved from https://docs.microsoft.com/en-us/sql/database-engine/sql-server-business-continuity-dr?view=sql-server-2017
Netwrix. (n.d.). SQL Server security best practices. Retrieved from https://www.netwrix.com/sql_server_security_best_practices.html
Tempdb Database. (2019). Retrieved from https://docs.microsoft.com/en-us/sql/relational-databases/databases/tempdb-database?view=sql-server-2017
Tintri. (n.d.). SQL AlwaysOn availability groups on Tintri. Retrieved from https://www.tintri.com/resources/whitepapers/sql-alwayson-availability-groups-tintri
Transparent Data Encryption. (2019). Retrieved from https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-2017