Securely storing data

Question

I understand the concepts of securely storing data for the most part, including storing the data on a separate server that only allows connections from the application, key-pairs for encryption, etc. However, I'm still not understanding how separating the server makes it that much more secure.

For instance, suppose I have a web server, which is hardened and secure, and it captures the data from user input for storage. The data is encrypted and submitted via a db query or web service to the db server. The db server only allows connections from the web server and stores the data in an encrypted form. Therefore, if someone access the db, the data is worthless.

But, if someone access the web server, they will have access to the db as well as the encryption algorithm and keys, no? That being the case, why even have the data on a different server, as the transfer of the data is just another potential point of attack?

Is there someway to hide the connection information and encryption algorithms on the web server so that if it is compromised, access to the db server is not gained? Obfuscation isn't enough, I wouldn't think. Any ideas are welcome.

Thanks Brian

Answer 1

There's a certain amount of magical thinking and folklore in the way people design for security, and you're right: storing data on a different server on its own doesn't necessarily make things more secure unless you've done all sorts of other things too.

Managing keys is a huge part of this; doing this in the context of web applications is a subject apart, and I'm not aware of any robust solutions for PHP. You're quite right - if your web application needs to be able to decrypt something, it needs access to the keys, and if the web app is compromized, the attacker also has access to the key.

This is why I've tended to use public key cryptography, and treated the public facing webserver as "write only" - i.e. the web server encrypts using the public key, stores in the database, and can never decrypt it; only a separate process (not available on the public internet) can use the private key to decrypt it. This way, you can store credit card details in your database, and only the application which charges the card has the private key to decrypt it; this app runs on a secure environment, not accessible from the internet.

Secondly, there are multiple levels of compromise - for instance, an attacker might get read-only access to your server's file system. If that file system includes the database, they could get hold of the data file, restore it to a server they control, and use the decryption key to steal your private data. If the database runs on a separate server(inaccessible from the internet), this attack route becomes impossible.

The fact that one route of attack leaves you open doesn't mean you can't protect against other attacks.

Answer 2

In most of my setups, the web server is in a DMZ of the firewall, and the DB is behind the firewall. I would never want to put the DB server outside the firewall. That extra level of security makes it much harder for someone to get to the data without authorization.

BTW, no web server on the net should be considered "hardened and secure". If it's available to the public, it can be hacked. It's just a matter of how hard they want to try.

You're right in your assumption that if someone hacks the webserver to the point they can log in as an admin, they can read and write the database. But that doesn't mean you should further weaken your setup by putting the DB on the web server. You want more security, not less.

EDIT:

Always think in terms of layers in your security. Separate critical parts into separate layers. This does two things. It makes it where the perp has more problems to solve, and it give you more time for detection and response.

So, in your scenario, access to the web server is one layer, you could then call an encryption server for a second layer (behind the firewall, which is another layer), and the encryption server could be the only machine allowed interaction with the DB server, which is another layer.

Layers make it more secure. They also, though, add burden, slowing the response time. So keep your solution balanced for your real-world requirements.

Answer 3

The problem here is that the keys are on the publicly-facing server which could be compromised - even if the server itself is "hardened", there may be a vulnerability in your app which gives an attacker access to keys or data.

To improve the security of your arrangement you could move just the code that handles encrypted data (along with the keys) onto a secure machine that can be accessed only by the web server, and only through a very restricted API (i.e. bare minimum that is needed). Each operation is logged in order to spot unusual behaviour, which could be symptomatic of an attempt to extract the secret data.

Answer 4

From a security perspective, putting the database into a separate server doesn't really help. If authentication tokens get compromised, it is game over.

However, it does make sense to separate database AND data access layer (DAL) from business logic and presentation. That way, if the application server falls prey to unscrupulous hands, database access is restricted to specific DAL operations which can go a long way of putting data out of harms way if properly implemented.

Other than that, there isn't much of a security benefit in segregating data storage into a separate server.