Today, database security is more important than ever. With data breaches and hacking in the news, we all know we have to do more in the area of security. Some of these risks can be reduced by applying encryption and hashing techniques, but doing this can be difficult to implement so developers sometimes only encrypt passwords, credit cards, or Social Security numbers.
The new SQL Server 2016 hopes to make encryption easier via the new “Always Encrypted” feature. This new feature provides an easy way to ensure that the sensitive columns in your database are always encrypted. In order to address performance concerns, non-sensitve columns such as primary keys can be left unencrypted.
The actual process is handled in the database driver level. While the database only sees encrypted values, the application code works exclusively with unencrypted data. When your query is executed, the driver automatically looks up the master key in the Windows Certificate Store. The master key is then used to decrypt a column specific key, which in turn is used for encrypting and decrypting fields and parameters. Currently the only driver that supports this feature is .NET 4.6.
Microsoft offers three use-cases for Always Encrypted.
Client and Data On-Premises
A customer has a client application and SQL Server both running on-premises, at their business location. The customer wants to hire an external vendor to administer SQL Server. In order to protect sensitive data stored in SQL Server, the customer uses Always Encrypted to ensure the separation of duties between database administrators and application administrators. The customer stores plaintext values of Always Encrypted keys in a trusted key store which the client application can access. SQL Server administrators have no access to the keys and, therefore, are unable to decrypt sensitive data stored in SQL Server.
Client On-Premises with Data in Azure
A customer has an on-premises client application at their business location. The application operates on sensitive data stored in a database hosted in Azure (for example in SQL Server running in a virtual machine on Microsoft Azure). The customer uses Always Encrypted and stores Always Encrypted keys in a trusted key store hosted on-premises, to ensure Microsoft cloud administrators have no access to sensitive data.
Client and Data in Azure
A customer has a client application, hosted in Microsoft Azure (e.g. in a worker role or a web role), which operates on sensitive data stored also stored in Microsoft Azure. The customer uses Always Encrypted to reduce security attack surface area (the data is always encrypted in the database and on the machine hosting the database).
SQL Server offers two encryption modes: deterministic and random. Deterministic encryption ensures that a given value always has the same encrypted representation. This allows you to use the column for equality comparisons, joins, and grouping.
The downside of deterministic encryption is that is can “allow unauthorized users to guess information about encrypted values by examining patterns in the encrypted column”. This is especially true when there are a small number of possible values.
For more security, you can use random encryption. Like salting a password, this prevents guessing by ensuring that a given value’s encrypted representation is never the same twice. Microsoft continues,
Use deterministic encryption for columns that will be used as search or grouping parameters, for example a government ID number. Use randomized encryption, for data such as confidential investigation comments, which are not grouped with other records, or used to join tables.
While there are limitations, we look forward to seeing this new feature in a test environment to verify if it works as well as expected.
The following Transact-SQL creates a column master key, column encryption key and a table with encrypted columns using the Always Encryption available in SQL Server 2016: