2

This question already has an answer here:

I'm trying to look into what kind of encryption I can do with SQL server standard edition from 2008 and later.

So far, I know that I can't use Transparent Data Encryption (TDE) as that's part of Extensible Key Management (EKM).

When I look up this topic I'm getting the result that column encryption is possible, but then I also find that cell level encryption is sometimes referred to as the same thing and that it is also part of EKM.

These are the sources from which I'm getting the contradictory information:

http://web.townsendsecurity.com/bid/72311/Encryption-Options-for-Microsoft-SQL-Server

http://www.experts-exchange.com/questions/27949443/Encryption-feature-of-SQL-server-2008-R2-standard-edition.html

Any clarity on this subject would be very helpful.

marked as duplicate by Tom V, Shawn Melton, Philᵀᴹ, Kin Shah sql-server Jan 21 '16 at 21:27

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • There are two third party options that support all versions and editions of SQL Server, down to Express. One is NetLib Encryptionizer and the other is DBDefence. They work differently however: Encryptionizer sits between SQL and the OS, while DBDefence injects code into the running SQL process using the (now defunct) Detours SDK. (Disclaimer: I am from NetLib Security) – Neil Weicher Apr 28 at 14:03
2

If you have SQL Server Standard edition then you do not have Encryption built into the product. You have other options as the articles you reference mention, but they require work on your part to implement.

I think the confusion is where you are seeing that you can implement column/cell encryption using Enterprise edition OR through alternative methods. Those alternative methods are:

  • Triggers and CLR functions to do the encryption/decryption for you.

  • Using the application layer to encrypt/decrypt the data on read and write to/from the database.

The advantage to using TDE is that SQL understands the encryption and you can search on the encrypted data directly because it is only encrypted on disk. But if you have encrypted the data using CLR or the application then you cannot do that and must decrypt every row.

Encryption is hard, don't roll your own. Find out what is required by the business, not managements "everything must be encrypted" and work towards that. You may be able to get away with seeing if the storage layer has encryption that can be implemented.

Not the answer you're looking for? Browse other questions tagged or ask your own question.