Drupal Security & Two DBs

Question

I use drupal for our site. It uses nodes that store data. We link lots of these nodes together to allow us to log jobs, customer info, invoices etc. These are linked via an addon drupal module. If I were to delete the links the entire site would be meaningless to me.

As this module is all that links the nodes together, I am thinking that from a security pov, I could create a database/app on another server and whenever drupal goes to get a linked node id, it will go via this other server (send a key and receive the correct nid in return). If the main database is stolen, the links will be meaningless and it will be basically worthless data.

Is this something that sounds viable and worthwhile?

Answer 1

It would cause a performance hit. Additionally, it depends on what you are concerned about having stolen. It's possible that even if you do this, an attacker might still be able to acquire your customer list, and potentially payment information if you are storing it.

Even if the data isn't useful in your application without a relation key, an attacker would probably be quite happy with the unrelated data if that data is coherent in any way.

Answer 2

No. I suspect this defense is probably not a great use of your time.

If you didn't have the links, the information would be hard for you to use -- hard for the good guys to use easily. That's bad for usability, because is information isn't easy to use, it probably isn't of much use to many of your users. But the bad guys aren't under those constraints. The bad guys could probably still gain a lot of sensitive information, and piece things together enough to give you a bad day.

Do you remember the story of Iranian revolutionary students who stormed the US embassy in Iran? The US residents shredded many of their documents before evacuating, but the Iranian students were still able to meticulously piece together the fragments of shredded documents into a whole, like a jigsaw puzzle. They had the time and patience to do it. Those shredded documents would have been pretty much useless to a legitimate authorized US diplomat, but they were enough for the attackers to work out a lot of sensitive information the US didn't want them to have. Security is often like that; the bad guys are willing to put in more effort to recover your data than any ordinary user of your site would be.

And in any case, if your site gets hacked, do you want to be in a position to tell the press "Oh, yeah, they got all the data, but they didn't get the links, so it's all good?" That doesn't sound like the kind of thing that is going to inspire trust among your customers. It's not a pretty picture.

So, I suggest you spend your energy elsewhere. Remember, security is a risk management effort. That means you need to prioritize where you spend your time, based upon what gives you the most security benefit for the least time, energy, and cost. I don't think this defense is a good one. Instead, I'd focus on the basics, things like application security (SDL), configuration management, network security, disaster preparation and recovery, internal education, and so forth. Most organizations have a lot of room to improve, even on the basics.

Answer 3

Considering such threat as 0 day, it is absolutely madatory, that you make sure that when the site is compromised, the main database is not stolen. You dont also expose yourself like Mat Honan with your address and have such huge security issues, by revealing the hole and providing your website address.

This can be implemented on the basis of external auth server who will mediate security between main server and nodes.

If you could describe in more technical detail what are you doing I could draw a some example.

Authentication server is using all security mechanism as well it has limited capability to serve only as auth and password recovery service so it's not exposed to common Drupal remote exploits. Also has passwords encrypted and so on. As well it's not exposed to internet, and has more strict filtering. This way, none of the sites / databases should be technically able to serve you any data before authenticating on it, and serve only data you have access to, via API, direct DB access or OO classes. This requires sometimes updates to DB and code too, like schemas and security checks, but first is OK to make sure that the root password of MySQL or anything else is not used anywhere, and that the admin login is changed to something else, as well the administration and access page are served only with FQDN as well the backend is accessible via hidden link (so it's not visible by the most scanners).