Best practice to secure data in a SQL Server 2008 database

Question

I have been creating an ASP.net web application for my client. This will be hosted in their organisation (this requirement is compulsory). One of their requirements is to secure the data in the database so their internal administrators and DBA's will not be able to see the data should they get onto the server or get hold of a backup of the DB.

I am using Linq-to-SQL and ADO.NET to query the db.

What is considered the best practice in securing the data contained in the database?

One of the options I am considering is adding a encrypt / decrypt layer between the business layer and the data access layer in the application to handle the protection of the data.

I am concerned this approach will degrade the db performance and application performance.

Any ideas or suggestions are welcome.

PS. An option that would be quick and easy to implement would be even better ;-)

Answer 1

Assumming you are using Windows 2008 or Windows 2008 R2 (or Vista or 7).

Do not encrypt the data in the database, it will degrade performance (to the point of snail speed) and you will lose a lot of database functionality.

Encrypt using BitLocker or EFS (with EFS you can encrypt only the database files, and is easier to setup and maintain; don't forget to backup the encryption certificates).

EFS:

Allow administrators to only backup using Windows Backup (command line with wbadmin should be enough, and you can provide that too). I recommend backing up the entire volume.

These backup administrators would log-in on that machine using SEPARATE credentials than the ones on which the SQL Server 2008 is running on, and they MUST NOT have access to the encryption keys and/or MUST NOT have them installed.

Backup administrators will be able to backup the encrypted files as they are, yet will never have access to them, as Windows Backup uses VHD as backup format (and the files are still on a NTFS volume, encrypted with those secret certificates).

Don't forget to not grant them permissions to log-in into the database and just read/dump data. Test this setup, and exercise a recovery (encrypted data is easily lost if you aren't prepared).