Keep the keys separate from the

 
3r3-31. I am starting a small series of articles about obvious solutions, which for some reason are often ignored by developers, although they are on the surface. This article will discuss security in administration modules and other internal modules of WEB projects.
 
 
The classic problem of a WEB-resource is the secure access to the admin panel of employees with privileged rights. It is solved by various methods. For example, a common solution is to place the admin panel in a separate module with placement on separate servers. You can bloat access certificates, VPN, 2F authorization, etc. etc. And of course, the engine on the division of rights in the system to weaken, plus logging. That's all. Happiness.
 
 
Ah, no there is one more thing: access to the database. Of course, access to the database will be from the admin from an individual user. It is clear why: the user from whom the admin works, there are many times more rights than a regular external user. Now that's it. Protected from all sides!
 
 
I propose to look at this decision critically:
 
 
 
Access to the database by all users is carried out through one DBMS account, the login and password from which is stored in the admin's config. Do I have to say that access to this data, for example, by developers, gives the latter the opportunity to manipulate the system uncontrollably?
 
The subsystem of differentiation of user rights is performed at the logical level. Those. in essence, it is formal. If the developer makes a mistake in the code or doesn’t take a careful look at the security of the code, an unscrupulous employee of the company can use this and get access to where he shouldn’t.
 
Unauthorized access to the server provides an attacker with access to the database accounting, which will allow him to gain full access to the system.
 
3r361
 
 
You must admit that these three drawbacks kill all the profits of any tricks on the security of the authorization itself in the admin panel. They lay a mine in the very foundation.
 
 
I propose to consider a different strategy proposed by the DBMS themselves. Namely: the separation of user access at the DBMS level. Those. Each user must have their own account in the DBMS. So “unusual” let's look at the profits:
 
 
 
Access to the database will be carried out through real DBMS accounting, which allows you to refuse to store user data using your own dvigla.
 
Logins and passwords are not needed in the admin config. Consequently, neither sysadmins, nor devops, nor developers have access to them.
 
Differentiation of access rights is performed at the DBMS level. Even kosyachny code will not allow the user to get access to where he should not get.
 
Many DBMSs can integrate with LDAP, which allows you to manage user access centrally.
 
It becomes possible to log user actions at the DBMS level.
 
3r361
 
 
Perhaps pedantic readers will have a question - how to maintain a user session? Do not store in the open form the login and password from the database in the browser.
 
 
The solution for this is quite simple. You can use the same redis, where after the first user login, save the login /password pair in an encrypted form, the key of which will be the session token. He, of course, nowhere to store. At the next request, we get a pair and decrypt by the transmitted token in the request. Connect to the database.
+ 0 -

Add comment