Est-il plus sûr de passer par une troisième base de données pour connecter deux bases de données en utilisant la même connexion?

Nous avons la configuration suivante:

Base de données de production multiple contenant des données privées utilisées par un logiciel de bureau
Une base de données Web pour un site Web public qui a besoin de certaines données des bases de données privées
Une base de données intermédiaire qui contient quelques vues et procédures stockées qui extraient des données des bases de données privées

Actuellement, le site Web se connecte à la base de données Web et la base de données Web se connecte à la base de données intermédiaire pour extraire des données ou exécuter des procédures stockées sur les bases de données de production. Toutes les bases de données se trouvent sur la même instance SQL et l'ensemble du processus utilise le même compte d'utilisateur.

Le compte d'utilisateur a un accès complet à la base de données Web et à la base de données intermédiaire, mais ne peut accéder qu'à des vues spécifiques et à des procédures stockées et à une base de données privée

Est-ce vraiment plus sûr que de simplement connecter la base de données publique directement aux bases de données privées?

Il semble que la base de données intermédiaire ne soit là que pour compliquer les choses car la même connexion est utilisée pour accéder aux données dans toutes les bases de données, et elle est déjà limitée aux seules vues / SP dont elle a besoin dans les bases de données privées. J'espère le supprimer.

database-design security

— Rachel
source

Vous avez un intermédiaire; ces procs / vues sur la base de données Web. Tant que vos perms sont définies correctement, la base de données supplémentaire semble être une abstraction inutile sans aucune implication de sécurité.

— Ben Brocka

@BenBrocka C'est ce que je pensais, mais je voulais revérifier avant de le supprimer complètement

— Rachel

Réponses:

Une chose saute ici:

L'ensemble du processus utilise le même ensemble d'informations d'identification de connexion

Problème

Ainsi, un utilisateur X hypothétique (qu'il s'agisse d'un sac de viande utilisant Excel ou d'IIS AppPool Identity) peut voir des vues et du code. Peu importe dans quelle base de données ces vues et ce code se trouvent, car userX est de toute façon configuré dans 3 bases de données.

Cependant, vous perdez le chaînage de propriété comme celui-ci.

Disons les WebDB.dbo.SomeProcappels PrivateDB.dbo.SomeTable. UserX nécessite des autorisations sur les deux objets. Si cela OneDB.WebGUI.SomeProcutilisait OneDB.dbo.SomeTablealors seulement les OneDB.WebGUI.SomeProcautorisations nécessaires. Les autorisations sur les objets référencés avec le même propriétaire ne sont pas vérifiées.

Remarque: Je n'ai pas examiné trop en profondeur le chaînage de la propriété de bases de données croisées . Je ne sais simplement vieux « Enchaînement de propriété » bien

Maintenant, selon les commentaires, vous avez vraiment 2 bases de données qui peuvent être combinées. Pas 3 qui était à l'origine implicite. Cependant, l'intermédiaire et le Web peuvent être combinés.

Les autres bases de données "privées" peuvent peut-être être combinées, mais ce sera un problème distinct. Voir le lien du bas pour une discussion plus complète sur "une ou plusieurs bases de données"

Solution?

Si les bases de données supplémentaires sont uniquement des conteneurs de code, les schémas sont une meilleure idée.

On dirait que vous avez utilisé "Base de données" où vous devez utiliser "Schéma" (dans le sens SQL Server, pas dans le sens MySQL). J'aurais un schéma WebGUI, un schéma d'assistance ou commun (pour remplacer la base de données intermédiaire) et un schéma de bureau. De cette façon, vous séparez les autorisations en fonction des clients et n'avez qu'une seule base de données

Avec une base de données (en plus du "chaînage de propriété"), vous pouvez également commencer à considérer les vues indexées, SCHEMABINDING (je l'utilise toujours) et ce qui ne peut pas être fait avec des bases de données séparées

Pour plus d'informations sur les schémas, consultez ces questions:

Enfin, il ne semble pas y avoir de raison d'avoir des bases de données distinctes basées sur "l'intégrité transactionnelle non requise". Voir cette question pour expliquer ceci: Critères de décision sur le moment d'utiliser un schéma non-dbo par rapport à une nouvelle base de données

— gbn
source

Je vous remercie. Il y a plusieurs raisons pour lesquelles les données Web se trouvent dans une base de données distincte, mais la plus importante est qu'il existe en fait plusieurs bases de données privées, et la base Web est responsable d'aller à la base de données privée correcte pour obtenir des données. Ma principale préoccupation était de savoir si la base de données intermédiaire ajoutait réellement quelque chose à la sécurité du site parce que j'aimerais le supprimer. Jusqu'à présent, il semble qu'il n'ajoute rien d'autre qu'une couche supplémentaire de complexité.

— Rachel

@Rachel: le bit "plusieurs bases de données privées" est tout à fait pertinent pour toute réponse, en particulier celle-ci ... J'aurais dit quelque chose de différent si cela avait été connu

— gbn

@Rachel: pourquoi vous n'avez pas mentionné les "multiples PrivateDB" sur la question? Cela change tout ...; - \

— Fabricio Araujo

@FabricioAraujo J'ai modifié ma question il y a 2 heures pour inclure cette information. Je ne pensais pas que cela importait à l'époque, car je posais des questions sur la sécurité de l'arrangement de la base de données, pas sur sa conception.

— Rachel

@FabricioAraujo: les conditions requises définissent la conception, donc une conception doit être correcte avant d'être sécurisée. Une conception incorrecte sécurisée est sans valeur - une conception correcte non sécurisée peut être sécurisée à tout moment.

— Fabricio Araujo

La réponse est: cela dépend. Si la base de données privée n'est pas accessible à partir d'un réseau local interne (ou uniquement via un VPN), ce schéma ajoute la sécurité, car une personne utilisant les informations d'identification du site Web aurait un accès limité à ce serveur de base de données privé (et aura encore du travail à faire pour obtenir dans votre réseau interne - temps qui peut être utile pour découvrir l'intrusion et fermer le trou).

Sinon, je ne pense pas que cela ajoute autre chose que de la complexité.

ÉDITER:

On dirait que j'ai mal lu votre question, alors voyons si j'ai bien compris maintenant: IntermDb est une base de données vide juste pour se connecter à PrivateDB OU c'est une base de données qui a ses propres vues / procédure qui se connecte à PrivateDB pour récupérer des données ?

Dans le premier cas, WTF? Déchire-le. Cela ne vaut rien, à moins que quelqu'un veuille le vérifier pour profiler l'accès à PrivateDB de manière plus paresseuse (et faire travailler les développeurs WebApp plus dur). SQL Profiler peut filtrer à l'aide de DB_ID ...

Dans le deuxième cas, je maintiens ma réponse précédente.

EDIT: "Je ne vois toujours pas comment cela est plus sûr que de connecter la base de données privée directement à la base de données publique car les 3 bases de données sur la même instance SQL et la connexion utilisée pour les 3 bases de données sont les mêmes et ne peuvent accéder qu'à des vues spécifiques et des procédures stockées dans la base de données privée de toute façon ".

Avoir l'intermédiaire signifie que l'envahisseur devrait creuser dans votre code connaître l'existence d'un IntermDB - et il doit creuser votre code dessus pour savoir qu'il existe un PrivateDB.

Si vous placez votre PrivateDB sur un autre serveur interne à votre organisation LAN / WAN (si possible), cela peut donner suffisamment de temps à l'administrateur pour détecter et bloquer la tentative d'invasion. Si vous utilisez des synonymes, ce mouvement est fluide car tout ce que vous avez est de les reconstruire dans le code existant, allez au bon endroit.

Vous bénéficiez également d'autres avantages: puisque tout le code doit passer par IntermDB pour accéder aux données dans PrivateDB, aucun développeur ne serait tenté d'essayer de le contourner - et cette tentative peut être facilement repérée sur SQL Server Profiler comme DB_ID de la demande de données PrivateDb serait WebAppDb.

— Fabricio Araujo
source

La sécurité ne serait-elle pas la même que si vous aviez la base de données publique sur un serveur et la privée sur un autre? Que fait l'ajout d'une 3e base de données à ce schéma pour augmenter la sécurité? Bien que dans ma situation, les 3 bases de données se trouvent sur la même instance de serveur SQL (j'ai également ajouté cette information à ma question)

— Rachel

En réponse à votre modification, la base de données du milieu contient ses propres vues et procédures stockées qui renvoient les données de la base de données privée. Je ne vois toujours pas comment cela est plus sûr que de connecter la base de données privée directement à la base de données publique car les 3 bases de données sur la même instance SQL et la connexion utilisée pour les 3 bases de données sont les mêmes, et ne peuvent accéder qu'à des vues spécifiques et procédures stockées dans la base de données privée de toute façon

— Rachel