I am trying to determine whether I need to use transparent database encryption (TDE) or encryption at web server to protect data in a database.

Here are a couple articles I've read on the subject, which seem to hold slightly different opinions: article 1 | article 2

The question I keep coming across is "who are you trying to protect data from?". And the options seem to be protecting data from a database administrator account vs external users.

I am not positive what my answer to this question is, so which group am I trying to protect from?

Further info: I am storing user-specific, confidential information in a database. The only person authorized to see this information is the user who has signed in using a username and password. The data needs to be protected in as many situations as possible.

  • What kind of queries do you need to run on user data? – Matrix Jul 17 '12 at 16:19
  • 2
    Given the requirements it looks like you need to do both. It doesn't have to be one or the other. – GdD Jul 17 '12 at 16:43
  • I don't know much about database queries - what are the possible answers to your question? – crawfish Jul 17 '12 at 17:44
  • The technical terms of encryption mean to say a web server or a destination server where actually we hosted our site might be protected, Is this your question. The techno difference might have been persisting registrar to registrar, if I am correct the registrar like thewebpole.com might be an administrator of a data base who technically administering a data base protection. If i am right you are thinking of protecting the data base in administer side. Is it so? – user8698 Jul 18 '12 at 5:37

transparent database encryption (TDE) or encryption at web server to protect data in a database.

Transparent database encryption means that you can't bypass database access controls by looking at the files stored on the disk. You say your information is confidential; you should be doing this.

Encryption at web server -- sounds vague; could mean one of two things:

  1. Disk encryption of the web server's hard disk (or encryption of the directory on the hard disk where the database is stored). Seems unnecessary to protect data in the database if you have TDE enabled. Granted their could be other sensitive data on the disk (e.g., the web server code that an attacker could exploit to find holes), so you could consider disk encryption in that case. Note, full disk encryption really only protects you for the case of physically going to the server and removing a hard drive and loading it into another computer to look at the data. (But the idea behind TDE is that all the data in the DB is inaccessible).

  2. Encryption for data transfer. That is your web server is HTTPS-only with clients accessing your site only though a valid trusted certificate, so all connections/data transfers to your application are encrypted to anyone eavesdropping for network traffic. You definitely need this if you want to keep your data secure; otherwise its trivial to steal another user's authentication information to get at their confidential information.

  • Thanks for the answer. I currently use a "user-encryption" described briefly above by Igal, in which I encrypt a field when it is submitted by the user and store that field in its encrypted state in the database. To decrypt I remove the field from the database, and decrypt in similar fashion. Do you believe this approach would benefit from (redundantly) implementing TDE? - thanks, crawfish – crawfish Jul 23 '12 at 14:26
  • @crawfish - In principle, there's no difference between transparent disk encryption and encrypting/decrypting all the sensitive fields yourself; its just simpler to setup and manage without accidentally introducing a vulnerability. E.g., the application/database caches the decryption key in a (temporary) table/file/memory somewhere that an admin could access or there's an attack at the way you are implementing encryption. For that reason, I'd prefer TDE to storing/pulling application encrypted data in the db. The downside of doing both is possible performance hit and cost of implementing. – dr jimbob Jul 23 '12 at 15:13

This is where understanding your risks and threats is essential - every industry and every organisation has a different risk profile.

To give you a couple of examples:

  • A global oil company's key threat actors may be ecological activists, terrorists, foreign governments and competitors - all external, but with different attack vectors. Foreign governments may use well funded stealthy exploits in order to gain access to valuable well data, whereas terrorists may be more concerned with physical access to wells in order to plant explosives.

  • A health service, while wanting to protect private medical data from disclosure, may have a stronger priority of maintaining system uptime in order to provide healthcare services to critically ill patients. Their key threat identified may be the risk of outage, so controls will be focused around that rather than preventing an attacker gaining access.

So have you carried out an assessment of your risks and threat groups? Is the data in your database subject to regulation where you are?

Realistically, if that data is sensitive, you will want controls to prevent dbA's tampering with data and to prevent external parties gaining access - but your risk and threat assessment may guide the balance of spend on controls.

  • In your global oil case, the threats are not strictly external. E.g., a disgruntled employees may be turned secret activist or data thief for the competition/wikileaks. – dr jimbob Jul 18 '12 at 13:37
  • absolutely - I was just giving examples of key threats :-) – Rory Alsop Jul 18 '12 at 13:52

Securosis actually did a great job (no surprise here), covering this in their article.

I'm not sure if I got enough info here, but if - as I`m guessing - we are talking about multi-user setup in which each user has access privileges for his/hers DB "partition" then for me this is classified more as a User Encryption/Tokenization scenario.

Having said that, I fully agree with @Greg_Dolph. This is not an "only one right answer" situation, and in this case "both" is probably the right way to go.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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