I work on a project related to agricultural production. The customer is very sensitive to security issues. One of the items of the technical specification is the use for each user of a separate database. The argument of this approach is the security of the system and if the attackers break into one base, they will not be able to get to the others.
When I replied that I’ve come across this approach to building a database structure for the first time and, perhaps, this approach is not practiced. However, the customer replied that he had already created a product that uses this principle, one user - one database.

Therefore, there are two questions:

  1. How this approach is right / wrong and how it is possible to implement it.
  2. If this approach is wrong, how to argue it to the customer?

It should be borne in mind that the application has a client-server architecture.

  • one
    I tried to give the question a more accurate name. Please edit if you think otherwise) - Kromster
  • Does each user work with an isolated dataset? That is, it is about multi-tenancy? - Nofate ♦
  • @Nofate thanks, now I recognize this term. Yes, it is about him. It is like a web application to control the work of individual enterprises. - Valentine Murnik
  • @Kromster thanks, come on) - Valentine Murnik am
  • 2
    As an option to isolate access, it is reasonable, but very costly (for me, it does not pay for closing risks). I would present it exactly to the customer, returning responsibility for the costs to him. - etki

1 answer 1

The approach is quite possible and in some cases - logical. Such architecture is called multi-tenant, most often used in cloud technologies.

Clear advantages:

  • Sql access for a specific client can (I would even say you need to) further restrict sql accounting.
  • Customer independence from each other.
  • Independence of customer data from each other.

What is not entirely clear on your question and you will need to consider:

  • Is there a common entry point for service operations? It must either be protected from clients, or clients from it.
  • What is the architecture of the application - client-database or client-server-database? In the first case, a separate customer base appears mandatory, in the second, depending on the workload and customer requirements.
  • Do customers need the ability to upgrade to different versions of the program? One base at all will not give you that opportunity.

You can find more reasons, you need to look at the situation.

  • Thanks, the situation clears up, I will answer about the questions. 1. There will not be a common point, because the customer is focused on security; there will be no access to the data of other users in the admin panel. 2. Client-server-DB architecture. 3. I think the issue of versions is always relevant, I will leave it as an argument. - Valentine Murnik