How to protect yourself from a sysadmin and a programmer by storing secret data in a database?

Question

PostgreSQL

There is a resource management web application (assignment of personnel to projects) built on the basis of PostgreSQL and Java.
There was a need to store highly secret data (contract rates and salaries of people) in the database. It is clear that this data should not be available to the database system administrator and programmer under any changes in the system, even if they copied the operational database and try to "play" with it in order to get this data from there. But at the same time, this data should be available to several groups of users. Someone for reading, someone for reading-writing. Ideally, even these groups of users should not be able to read each other's data, unless they are part of a highly privileged group that everyone can read.
The system already has a branched privilege scheme, but no protection from the administrator was done, because. it is possible to directly add privileges through the database.
Obviously, these secret data (secret fields) should at least be encrypted at the database level to prevent direct reading. But how to protect yourself from interception of passwords or encryption keys by programmers and system administrators?
Recommend articles or examples of (non-proprietary) architectural solutions in Java to achieve the above.

Answer 1

You can try this option:
1) In a web application, make data encryption a symmetric algorithm on the client side
2) The admin and the programmer should not participate in the generation of encryption keys for the algorithm
3) Users are given keys to access information.
Total:
1) Data in the database is stored in encrypted form
2) Data between the database and the application is encrypted
3) Keys are stored by users and are not transmitted anywhere

Answer 2

Salary data is brought into the project, probably not only to be stored there, but also somehow participate in the calculations.
Therefore, if you have a three-link, then it is impossible to protect yourself from the application server admin - the data must be there in decrypted form.
If it is possible to work on these "highly secret" data according to a two-tier scheme - in the client browser, then yes, encryption with due precautions (with randomization and protection against replay attacks) will save you in principle. Although the task will still be non-trivial.
PS By the way, are you sure that the rate cannot be "calculated back", knowing the amount of payment for the stage and its labor costs in hours?

Answer 3

Not really an answer to your question, but still. Calling information about the RFP "highly secret" is, to put it mildly, wrong. They are not secret, but confidential, and are usually protected by clauses in the employment contract. It seems to me that the problem you have now is that the task has been set, divorced from reality. You are trying to spend a lot of time on development, while creating a lot of problems in subsequent support - on fiction. Even with successful implementation, think about what will improve in the enterprise? Employees will stop communicating with each other (including quietly wondering who "receives" how much)? When publishing a resume, the company will no longer indicate the fork of the RFP? I would recommend that you seriously think about setting the task, it is very similar to firing a cannon at sparrows ...

Answer 4

To sim3x: I have something like this scheme and I assume that programmers do everything, the code is reviewed for the lack of secret data in the system or server logs (so far the problem is with the database logs), the admins are preparing the deployment procedure (and possibly even deploying) I generate the keys myself I train users. But the problem of intercepting either the key or the password to the key is still invincible.
To m0rd: This option is possible and should be implemented. Only it is not yet clear how (I would like an example of microarchitecture).
Those. everything is obtained in an open way from the UI level (working via SSL with the server) and back too, and is encrypted on the backend. Until the moment of encryption, everything needs to be reviewed very carefully so that no interceptions in the code occur and no introduction of foreign code is possible (especially on the UI). You can encrypt with both a symmetric and an asymmetric key (then the caching area of ​​the keys on the pages can be different). And the already encrypted data will go to the side of the database. Thus, we protect ourselves from the so far invincible lower-level database logs. Those. Encryption keys are provided by the user each time.
But this is all theory. Certainly. I would like to see an example. And then I suspect a large number of invisible "rakes" that I would not want to step on in advance.