Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I'm working on a rails app for our church, which stores some fairly sensitive information about our people in a MySQL database.

We have our own windows server running Hyper-V so the original intention was to spin up a VM and host on there.

Long term this sounds like the best solution, but at the moment our church has fairly poor internet connectivity (home ADSL) and I don't want to waste time now maintaining infrastructure and talking to service providers when I could be putting more time and energy into building a great app.

In this initial period I'd like to host our app on a VPS with Linode, Rackspace or Amazon.

Our leadership's concern (quite rightly) is security of our people's data, and while I can assure them all communication will be SSL encrypted over HTTPS they are still concerned about storing our data with a 3rd party.

In the scheme of things our data isn't a prime target for attackers, but I'd like to be able to give them the assurance that even if our server was wide open for any member of the public to log in and browse around the data would remain secure.

Is this possible?
Can a MySQL database be encrypted on disk to this level, but stil be accessible over a MySQL connection (via a socket or TCP port)?


On second thoughts I'm thinking it'd be a bit redundant anyway as the database connection credentials will need to be stored on disk for the rails app anyway!

share|improve this question

migrated from serverfault.com Sep 29 '12 at 18:22

This question came from our site for system and network administrators.

3 Answers 3

up vote 2 down vote accepted

On second thoughts I'm thinking it'd be a bit redundant anyway as the database connection credentials will need to be stored on disk for the rails app anyway!

You've essentially summarised your problem.

Even if you could encrypt the MySQL store - "all" they have to do is compromise your web server, and they get your DB credentials and can happily dump your database. The fact really is that if they can get the same level of access as you at any point - all your security efforts have gone down the drain.

Here are some general tips, but they don't replace your professional security advice:

  • Minimise access. Never have a user that can access the database server from any IP address, you're just begging for a brute-force attack. Instead, tweak the external firewall (e.g. the one EC2 called "Security groups") so only your web server can even connect to your DB server. The less people that know your VPS is a DB server, the better.
  • Make sure everything else is secure. That means your email passwords, security answers, and so on. If they can get access to your EC2 account or your email account, you've just completely wasted your time securing the instance. Social engineering attack are all the rage these days, don't let yourself be next.
  • Ensure your VPS instance is bare-metal. Don't have software on there that doesn't need to be, that even goes for sendmail (this is just an example of how, back then, you might have though "sendmail can't hurt to leave on!"). Anything that is there, keep updated frequently and watch out for security notices.
  • Try to avoid having any services in general that are public facing, especially something like SSH. If you must, disable password authentication and put SSH on a non-standard port (then connect to it like ssh -p <port> user@host as normal.

Having said all of this, it won't make your case to the client any better. You'll still say "it's as secure as it can be" but not "the data is encrypted on disk".

share|improve this answer
    
+1; agree, but having said that, implementing this encryption could spare some blushes if somebody manages to gain access to the DB only. So whilst not a perfect solutions, it's a step in the right direction. –  Bryan Sep 29 '12 at 16:46
    
That's true, but it's relatively simple to firewall your server so it'll only accept connections from specific IP addresses. I know that's true for EC2, so I assume the others too, and I'd be surprised if you could circumvent that easily (with TCP). –  Jay Sep 29 '12 at 16:55
    
Thanks for your insight @Jay, that's pretty much what I was thinking... most of these security problems exist whether we host on a VPS or self host. Infact, many providers offer help + support tightening the security of your instance! –  Daniel Upton Sep 29 '12 at 22:53

You could make use of native MySQL encryption and require each user accessing the web app to also provide the encryption key along with his user credentials

http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html#function_aes-encrypt

Without the correct encryption key, stored data could be accessed.

That would allow you to protect your web app from external hacking too and the weak link becomes the user. The user is the one that's asking you for additional protection. In case of a security failure or leak they would be at fault as without knowing the AES encryption key nothing could have happened.

This will allow you to store any kind of data without having to make use of full disk encryption. Keep in mind with a virtual environment the entire system image could be copied, and analyzed along with all the data in it, whereas on a bare metal machine this is harder, more expensive and the system admin would notice it more easily.

This approach is not feasible if the app needs to operate by its own with crontab or something similar when there is no resident key on the MySQL AES instance.

share|improve this answer
    
Thanks very much @evcz, I think ultimately the weak link will always be the user... which is becoming glaringly obvious these days: codinghorror.com/blog/2012/09/computer-crime-then-and-now.html –  Daniel Upton Sep 29 '12 at 22:58

Re: SSH, don't use password authentication; disable that, and use public/private key authentication instead, ideally IP-restricted to your own IP. This cuts down on brute force password attacks, since a key is absolutely required. Also don't allow root login. On Ubuntu, use sudo (super users).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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