Are there databases, storages, backends for sensitive data?

Question

SQL

With web applications, there is a problem that in the event of a vulnerability in it, you can immediately lose almost all the data that the application has access to, and SQL security tools do not allow you to reliably and fine-tune access rights.
For example, if the application has SQL Injection, then finding it, the attacker simply issues a SELECT * FROM customers query; and gets a list of all clients with passwords. He can do this because the SQL language makes it possible. Although from a security point of view, the frontend never needs such a dangerous operation (but it needs access to the customers table).
Therefore, there is an idea: what if we divide the data and store it differently? 99% of the data (they are already public or not too expensive, for example, a list of goods, descriptions, pictures, prices) will be in a regular DBMS. The existing application is 99% unchanged. But we take out 1% somewhere on .... (I don’t know what to call it here, let’s call it secure backend) and work with it using an API that, unlike SQL, is focused on security. As a result, we have:
1. Even full access to the database does not give access to the secure backend
2. Even root access to the server still does not open the possibility to merge everything with the secure backend!
Examples of how it could work:
Login
When logging in, there is an option to check that the username/password matches. (But you can't even get the password hash). Optional - maybe even a ratelimit for these operations so that bruteforce is not allowed. For example, the IP of the client is passed, and more than 10 requests per minute cause a block.
After login, the possibility of reading the client's profile opens. For example, delivery address, purchase history, etc. Alternatively, this history is already stored in SQL, but without some kind of client id, it is impossible to link them without performing a successful login procedure. A burglar can find out that on the 21st a bedside table was bought, but he bought it secure:user:id:123, and he does not know who it is.
Non-SQL restrictions
An operator in a bank branch serves on average 20 people a day (let's say), we allocate a limit to him, he can request data on 50 bank customers from this city, and 5 from other cities (to avoid the situation "where you received the card, go there) This does not interfere with his normal work, but in principle he cannot merge the entire database of all bank customers (via SQL, a web application with a vulnerability - it can)
Different user roles
The web application establishes a connection to the API just like a web application and has its own "profile" (access rules). For example, in principle it cannot get a list of all clients, ever. Admin - maybe. But in order for the application to "log in" as an admin panel - firstly, you need to change the application code (i.e. get root on the frontend server), and secondly, go through the additional. restrictions, for example, knowing the admin password, but it is never entered on the frontend, or in general, the admin can only work from other IP addresses.
Are there already ready-made similar solutions for something like this?

Answer 1

Look at WAFs, especially Database Firewalls ( https://www.imperva.com/ etc.)
There are tips for secure architecture from OWASP,
for auditing on PCI, SOC2.

Answer 2

This can be done by fine-tuning constraints, plus stored procedures and triggers. But usually they don’t do this because it significantly complicates the system and can have an extremely negative impact on performance (and where such security is important, performance is usually also important).

Answer 3

Hmm, well, in addition to all the answers, I can offer Hashicorp Vault

Answer 4

Look in the direction of mandate control, these are primarily SELinux-based solutions, and the main DBMS support them.

Answer 5

For example, if the application has SQL Injection, then, having found it, the cracker simply issues a SELECT * FROM customers query; and gets a list of all clients with passwords. He can do this because the SQL language makes it possible. Although from a security point of view, the frontend never needs such a dangerous operation (but it needs access to the customers table).

There is a heap of decisions:
1) the DBMS gives such possibility. But it is not at all necessary that the SQL user used by the frontend has access to the customers table, where passwords are stored. To other tables - please. To this one, no. Password verification - only through a separate server like oAuth.
2) The DBMS has a lot of fine tuning of access restrictions, even if you need to give access to the customers table where passwords are stored.
https://www.postgresql.org/docs/10/ddl-rowsecurity.html
https://docs.microsoft.com/en-us/sql/relational-da...
3) You don't need to store passwords. It is enough to store the "salted hash". Getting salted hashes won't do anything.
https://habr.com/en/post/145648/
https://habr.com/en/post/210760/
https://habr.com/en/post/145667/
https://habr.com/en/post/39079/
4) There are specialized databases for storing secrets.
They are unlike conventional DBMS. unrecoverable, even if an attacker steals all the DBMS files.
They also allow auditing.
They also allow you to organize password revocation, etc.
It is clear that the task cannot be completely solved, since if an attacker gets inside and receives a token for accessing the data, then he will get to the data itself here too.
But at least this access will be limited in time.
https://habr.com/en/company/oleg-bunin/blog/438740/
https://habr.com/en/post/306812/
5) You can not store passwords in the usual form in the DBMS at all, but transfer them to the application at startup through environment variables.
etc.
Etc.
6) Restriction of simple enumeration. Avoid using identifiers like 1, 2, 3, 4, 5. Instead, use something like 0xF6C0F6C5430DC8904F60ABE822345200 and add throttling to limit the brute force. Not to mention the hard blocking by IP with too many brute force attempts.
7) And why would he be given at least something at such a request?
And why does your backend perform an unforeseen request at all on someone's orders? I have it in the code and the provided requests are not so easy to get to execute. They are carried out only within the strict limits of what is permitted and provided for during development.
SQL Injection is not possible at all with the modern approach, the code only executes what is provided; when modern frameworks and modern libraries are used, where everything is filtered several times.
Your example is something from 2000-2010s. For a long time already, a similar code that allows everything has not been practiced.
Although, of course, programmers are different ....
In short, there are a lot of protection methods.
Because you can access it.
It's basically a matter of divide and conquer.
So that even having received something somewhere, the attacker could not do much harmful.

Answer 6

the attacker simply issues a SELECT * FROM customers; and gets a list of all clients with passwords

In a normal database, he will receive not passwords, but hashes that are useless for him

Answer 7

This is solved by an additional layer that implements an "external" API.
The client application instead requests A, the script decides whether to issue data to the user or not, whether he has kept within the limits or not. The same script writes request logs and informs anyone who needs it about suspicious activity. There should be no direct contact between the client application and the DBMS.