Combinaison de base de données pour plusieurs clients - bonne idée?

Question

J'ai rejoint une petite entreprise qui vend essentiellement une application web. Les données de l'application Web sont très sensibles, au point que toutes les données sont cryptées au niveau du champ. L'application est écrite en ASP.NET Web API 2 (C#), avec un front html/javascript et SQL-Server en arrière. À l'heure actuelle, ils ont environ 50 clients, et l'architecture de l'application est que chaque client obtient sa propre base de données. Ils sont tous déployés dans leur propre répertoire virtuel IIS, qui pointe ensuite vers sa propre base de données. Le code est exactement le même parmi tous les clients.

Le propriétaire m'a dit que tout cela était conçu pour des raisons de sécurité. Cependant, c'est une douleur absolue à gérer, et ils obtiennent seulement plus de clients.

J'ai suggéré de combiner tout cela en un seul DB, et d'ajouter un champ sur la table principale qui identifie le client auquel les données appartiennent. De là, je peux filtrer/rejoindre sur ce champ. Le propriétaire n'aime pas cela car cela introduit un risque: s'il y a du code de mauvaise qualité, un client peut être capable de voir les données d'un autre client. Cela ne peut évidemment pas se produire avec plusieurs bases de données, car la chaîne de connexion ne se croise pas avec une base de données différente.

Existe-t-il un moyen possible de réduire ce risque? J'ai suggéré de surcharger la classe authorize pour empêcher les utilisateurs non autorisés d'accéder aux informations, mais cela ne résout pas tout le problème du 'mauvais code'.

Y a-t-il quelque chose que je puisse faire, ou est-ce que je suis coincé en conservant un tas de bases de données?

Answer 1

Il existe également un risque dans la configuration actuelle. Que faire si quelqu'un mélange les chaînes de connexion à la base de données sur les sites? Vous devrez déterminer lequel est le plus risqué.

Si vous décidez de conserver les bases de données séparées, il semble que vous ayez besoin d'investir dans l'automatisation pour les gérer. Nous utilisons un projet de base de données pour contrôler le schéma de la base de données/scripts de base de données et MSDeploy pour automatiser les déploiements à toutes les bases de données. Peut-être que cela augmenterait une partie de votre douleur avec les bases de données multiples.

http://dotnetcatch.com/2016/02/10/deploying-a-database-project-with-msdeploy/

Answer 2

Je ne pense pas que ici est un droit ou une mauvaise réponse ici, il est vraiment à l'appétit pour le risque de la société donnée (ou son propriétaire).

Il semble beaucoup moins probable qu'une chaîne de connexion pointe vers la mauvaise base de données, que d'écrire un code qui tire accidentellement (ou intentionnellement) les données d'une autre société à partir d'une base de données unique.

L'architecture de base de données séparée offre un énorme avantage sur la base de données partagée, en plus de la sécurité: c'est la restauration des données. Dans le cas où vous ne devez restaurer que les données d'un seul client, la conception de la base de données séparée vous permet de le faire de manière à ne pas affecter les autres clients. Dans le cas d'une base de données partagée, toute procédure de restauration affecterait également le service des autres clients.

Il peut y avoir un compromis entre des bases de données séparées et une base de données partagée: schéma distinct. Si vous utilisez cette approche, les schémas distincts conservent un certain degré de séparation, mais vous disposez de beaucoup moins d'instances de base de données à gérer, ce qui permet au service de mieux évoluer.

Il existe un bon article sur MSDN qui examine les trois options: Multi-Tenant Data Architecture. L'artice décrit les avantages et les inconvénients des trois scénarios.

Cependant, SVP gardez à l'esprit que tout cela dépend vraiment de l'appétit pour le risque subjectif de votre entreprise!