A few weeks ago, I wrote Part 1, 2, and 3 of this series which was a beginner’s guide to Always Encrypted. In part 4, I am going to talk about the changes that are coming in vNext of SQL Server.
As I discussed in part 3 there are many roadsblocks the can stop the implementation of Always Encrypted (AE). In the currently available versions of SQL Server 2016 and 2017, along with Azure SQL Database, the cost of using AE was way too high for many companies. There are so many code changes needed to implement AE that moving to it is not cost effective for them. Microsoft recognizes this and has found a better way to handle things like aggregations, range comparison, LIKE predicates, ORDER BYs, and other search criteria with the introduction of Secure Enclaves. For the client discussed in part 1-3, this will make all the difference.
Per MSDN, “An enclave is a protected region of memory that acts as a trusted execution environment. An enclave appears as a black box to the containing process and to other processes running on the machine. There is no way to view the data or the code inside the enclave from the outside, even with a debugger.”
![SQL Server]()
Now, let’s translate that into English. It means that SQL Server will evaluate the encrypted data in PLAIN TEXT while it is a protected region of memory. Just like non-encrypted data, we can now treat it just like anything else when querying it. This all takes place on the hardware. The process is a little complex to explain but in short SQL Server Engine processes its own enclave (a fancy word meaning a portion of territory) in memory where it loads encryption algorithms and required instructions to run the submitted SQL code. Then, the SQL client sends the encryption keys, retrieved from a Windows Certificate or Azure Key vault to the enclave over a secure channel to decrypt the data and process the queries in plain text. This is the only place that data is unencrypted. All result sets are sent back encrypted over that same secure channel and can only be viewed after decrypting the data again by using the keys.
This is a real game changer, in my opinion, that will really help springboard Always Encrypted to the most used encryption option in SQL Server. If you want to give this a try, it’s still in preview but you can sign up to try it out here.
For a more in-depth understanding of the hardware side of secure enclaves, check out this paper here.