In the past, it has been common practice to use encryption as a means to protect sensitive data from disclosure and unauthorized change. There are several different encryption techniques commonly deployed, as follows:
A. Web site transmission encryption by the application (SSL)
B. Whole database encryption (done by the database)
C. Column encryption or obfuscation (done by the database)
D. Application field encryption or obfuscation (done by the application)
All of the above methods HELP to protect data, but none of them completely prevent a hacker from reading and/or modifying sensitive data. Let us examine each:
Technique A (SSL) prevents hackers from intercepting Web traffic, but they can still attack the server farm and the database(s).
Technique B (whole DB encryption) protects against hackers obtaining a file copy of the hard disk or a database backup stored offsite and then discovering data, however it does not prevent attacks by internal staff, nor hackers who have discovered DBA login credentials.
Technique C (column encryption or obfuscation) similarly protects backups (including data dumps), but will not deter internal attacks or hackers who discover DBA login credentials. Encrypted data generally cannot be queried for users who don't have access to that table, however the DBA login does have access to the table, and can't be denied.
Technique D (app field encryption or obfuscation) is the best of the lot, especially if an 'appliance' is involved which stores the keys and/or performs the encryption. However it does not deter hacking via SQL Injection, nor access by internal staff who have to perform production support (who need to have knowledge of the encryption design to perform their jobs).
We at dbDefend recommend using one or more encryption techniques, supplanted by dbDefend products to protect against ALL forms of database attacks. For more information on our products, click below: