My SQL Dump

MySQL musings by a self professed MySQL Geek

Previous Entry Share Next Entry
Transparent encryption does not make your database secure
swanhart
Transparently encrypted storage of *any* kind (storage engine based data encryption, truecrypt volume encryption, bitkeeper, etc) is *just as insecure* to most types of attack as non-encrypted data.  SQL injection or security escalation vulnerabilities, operating system vulnerabilities and cross site scripting attacks could give attackers access to the database data.  It doesn't matter if you encrypt the database's physical storage in the database itself (in the storage engine layer) or on disk (at the filesystem level) since either way the data is presented unencrypted through the SQL interface. 

Transparent encryption is great for protecting your laptop data from theft by stealing your laptop.  It is very unlikely someone will attack your server by stealing it.

It doesn't protect you from a malicious SQL injection which drops all your tables or reads all your data.

If you are worried about someone physically stealing your data, physical encryption can help with that, but it is very likely that you only need to encrypt off site backups or other data you ship to third parties.

Also, there is no functional difference between an encrypted cloud block device (eg, truecrypt encrypted EBS volume) and transparently encrypting data and storing it directly as S3 data.  

So, don't trust transparent encryption to "secure" your MySQL data.  You have to have a full set of security practices in place to ensure your entire stack is as safe as possible from attack.  Also, always back up your data.  Just because your data is stored in S3, it doesn't mean you won't accidentally delete a wrong row, drop a wrong table or get attacked by a vulnerability.

You are viewing swanhart