The goal here is to prevent identification of the users and their data. Is it a good idea to partition my database into multiple ones, one for each kind of sensitive data, hiding the links between them?
At first it seems that the answer is yes, because an attacker would need to gain access to all databases (potentially served from different servers/VMs/containers) in order to build the relationships between data and users, and identify them.
Of course doing so adds a lot of complexity to the application layer so I wonder if this is a good idea at all.
EDIT: here is a more concrete example.
The project is a website. The application code runs on server A. Connections are done from the application to databases db1, db2 and db3, respectively on hosts B, C and D. No encryption at all (excepts passwords of course). The application code holds credentials for all three databases. So I do have a "security bottleneck" and it's server A. Besides, relationships between data are not stored in a separate database, but splitted in the three databases.
Is this bad design? Would I be better off setting up
- only one database (in server E) and strictly securing server A and E? or
- another database to hold the links between data, to delay furthermore possible identification of users?
Other solutions to consider?
Would any of this even be useful considering server A is a single point of failure / security bottleneck?