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

Indomitability

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.

Johanna

Outstanding information, both there and the other answers. It made me realize that separating the data is not enough. The encrypt/decrypt functions also have to be separated, leaving the web server as "write only" as mentioned by Neville. Thanks to all for the insight! – Indomitability

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.

Conduplicate

Yes. But, if they access the web server, can they not then connect to the db from there? – Indomitability

You're "BTW" comment is exactly what I'm concerned about. On the web server is your connection settings to the db, along with any keys and encryption algorithm. It seems that access to the web server would also expose your db server. – Indomitability

If someone hacks to the point they get admin login access to the webserver, yes. But why make it easier by putting the DB on the webserver? With the separation, they have to get greater control than without the separation. – Conduplicate

It's almost like you're saying "My front door lock is easily picked, and once inside they can get my bank info, so why should I keep my money in a bank?" Security is always done in layers. – Conduplicate

Databases have levels of access defined by the user that's connecting to it. You can set your db access from the "secure" server in such a way that your data cannot be deleted by that user. That gives you another layer of protection in case your web server is compromised. Also, splitting the web server from the DB server isn't always just about security, it's about maintainability, availability and scaling. – Godparent

If we're simply talking about physically separating a web server and a db server, all you've done is added a trivial extra step. The data isn't any more secure. If I've hacked your web server I don't need to visit the teller; I get to reach directly into your bank. I may not be able to make a direct backup of your database, but I can crank out a quick script with a few select *'s and decrypt whatever I need to using that handy web API I saw when browsing the source of the checkout pages. In all seriousness, unless you are splitting into 3 physical web/app/db tiers what do you gain? – Arianna

@Sam, agreed, when we're talking separation and layers, we're talking logical separation. Physical means nothing, as one physical machine can host numerous virtual machines. – Conduplicate

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.

Juanitajuanne

This is good advice here. Keep in mind that a best-practice architecture would actually use three servers, a web server with NO application logic, an application server with all the code, and a database server. The web server is the only thing that can talk to the application server and the application server is the only thing that can talk to the database. If all interactions between the tiers are as minimal as they can be (as @Juanitajuanne suggests) and are mutually authenticated (2-way auth SSL) between the tiers, you've made an attack into the DB much, much, harder than if they were colocated. – Festus

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.

Andy