Is splitting databases a legitimate security measure?

Question

When previous devs at my company had to store sensitive user data (for example, medical records), they did the following. I doubt its merits.

1. There is data considered "insensitive" (user login, profile info), and "sensitive" (user medical records).
2. There are three databases. Insensitive data in A, medical records in B, and the mapping between A and B in C.
3. A hacker must hack all three databases to tie users (A) to medical records (B).

Our own backend code calls C to tie A and B data together for user display. I think the ubiquity of this code invalidates the benefit of splitting databases: if the hacker accesses our system, he can call our logic.

What benefits of the above system am I missing (or are there better ways to secure such data)?

Answer 1

I'd say that once your system has been compromised and the assailant is past the threshold with access, then the databases are just a matter of time. What it is doing is at least perhaps delaying to intruder in their intent - but the cost (in terms of maintenance, performance, project clarity and so on) might outweigh the benefits.

I'm sure there will be sufficient information for a determined person to decide that X, Y and Z databases are linked - unless you obfuscate database names, table names and other structural indicators.

Ideally you should be looking to make your system impenetrable, all other things beyond that are mitigations, the treating of symptoms with neglect for the problem (that you've been exploited), of which the trade-off must be considered uniquely to the situation.

In my experience and opinion, splitting the database like this is a strangely contrived approach to security that I find to be ingeniously silly.

Answer 2

In response to the general question "is splitting databases a legitimate security measure", isolation is indeed a well-known, useful tool for implementing security. Whether its benefits outweigh its drawbacks (generally, additional complexity) is very much situation-specific and I don't know the answer in your system's case.

Suppose for example that someone wanted to build an analytics application on top of your data. It would be very useful to have the mapping data completely out of the picture. If the analytics app is breached, the mapping information is not at risk.

Responding to some comments below, even in your system's specific case, it's not a foregone conclusion that "breaching the system" amounts to breaching all databases at once. Suppose that an attacker exploits a SQL injection vulnerability in your application. If the mapping data is separate and hardened (extra controls on code that accesses mappings, say), then isolation can be the difference between exposing unassociated data and associated data.

Not arguing that it is a good design for your system. Just trying to explain different kinds of rationale that can go into this.

I'm using the same isolation strategy in a similar situation. The "databases" in my case are configuration repositories. All of the preprod configuration goes in one repo and the production config goes in a separate repo. All developers have access to the preprod repo, but only release engineers have access to the prod repo. The rationale is that I want defense in depth: while I could certainly implement access controls on the individual repo folders, I'd rather make the production config simply network-unreachable to all unauthorized staff.

Answer 3

Yes, splitting data into separate stores can help security. As James Anderson writes, most database systems allow you to grant different privileges on individual tables.

However, most security analysis looks for the weakest link; I doubt whether your weakest link is the way your databases are split out. So, unless you've nailed down a whole bunch of other things - password management being an obvious one, SQL injection attacks another - at best, the database design is pointless; at worst, it is adding complexity to the application which causes bugs; most security vulnerabilities come from bugs.

It can also lead to a false sense of security - "we're covered on security, we split our databases", or a cavalier attitude to securing the "non-sensitive" data.

Oh, and if you decide that the user's login credentials are "not sensitive", you're basically giving an attacker the option of simply impersonating legitimate users of the system to steal your data once they have penetrated your "non-sensitive" data store.

Answer 4

On most serious DBMS systems you can control access at table (sometimes even row level).

So storing the sensitive data in separate tables is a valid way for restricting the access to the confidential data.

While nothing will protect you from a hacker who gets root (as other posters have pointed out). But this strategy will protect you from unauthorized users within your system gaining access, and, by extension from hackers who have obtained their userids and passwords. As spoofing low level employees into giving password details is still one of the commonest "attacks" this is well worth doing.

The big "if" is can you really split your users into "have access" and "have limited access" groups?