One of the ways we work to implement better security is through the use of encryption. I remember the early days of PGP, VPNs adding end to end encryption, IPSec becoming available, and more. I was excited to see column level encryption come in SQL Server 2005, but it was a bit complex to implement and had issues. The evolution over time with TDE and Always Encrypted were welcome additions, but we can do better.
Handling encryption in the database can provide some protection, but really, we’d like to see an end to end solution, that ensures data is protected on the wire as well as in the db. Microsoft does a lot of research, and released a Simple Encrypted Arithmetic Library (SEAL) as open source code. This is a C++ library that developers can use to protect their communications. Last year they also released a .NET wrapper to make it easier for a wide variety of developers to use.
There is a lot more to deal with when handling encrypted at scale. Indexing and search operations are difficult and complex, and can require lots of resources. I think that the Always Encrypted in SQL Server 2019 with Secure Enclaves is a good evolution, but it’s complex to set up, tooling is poor, and maybe more disconcerting, there are potential vulnerabilities with secure enclaves on Intel chips.
Certainly a combination of developers being able to use something like SEAL and a linkage with a secure enclave on the server for set-based operations might be something we can look forward to in the future. I hope so, as security continues to be a challenge for many of us.
I’d also like to see more software that is built to ensure users can’t access huge amounts of data, and perhaps easier ways to control the export of large amounts of data. We do need this capability, but we also want very few people, or no people and only a process, with rights to do so.
Steve Jones
Listen to the podcast at Libsyn, Stitcher or iTunes.
