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.