Ist es sicherer, eine dritte Datenbank zu durchlaufen, um zwei Datenbanken mit demselben Login zu verbinden?

Wir haben das folgende Setup:

• Mehrere Produktionsdatenbanken mit privaten Daten, die von Desktop-Software verwendet werden
• Eine Webdatenbank für eine öffentliche Website, die einige Daten aus den privaten Datenbanken benötigt
• Eine Zwischendatenbank, die einige Ansichten und gespeicherte Prozeduren enthält, mit denen Daten aus den privaten Datenbanken abgerufen werden

Derzeit meldet sich die Website bei der Webdatenbank an, und die Webdatenbank stellt eine Verbindung zur Zwischendatenbank her, um Daten abzurufen oder gespeicherte Prozeduren in den Produktionsdatenbanken auszuführen. Alle Datenbanken befinden sich in derselben SQL-Instanz, und der gesamte Prozess verwendet dasselbe Benutzerkonto.

Das Benutzerkonto hat uneingeschränkten Zugriff auf die Webdatenbank und die Zwischendatenbank, kann jedoch nur auf bestimmte Ansichten und gespeicherte Prozeduren einer privaten Datenbank zugreifen

Ist dies wirklich sicherer, als die öffentliche Datenbank direkt mit der privaten Datenbank zu verbinden?

Es sieht so aus, als ob die Zwischendatenbank nur dazu da ist, die Dinge zu komplizieren, da dieselbe Anmeldung für den Zugriff auf Daten in allen Datenbanken verwendet wird und sie bereits auf die Ansichten / SPs beschränkt ist, die in den privaten Datenbanken benötigt werden. Ich hoffe es zu entfernen.

Eines springt hier raus:

Der gesamte Prozess verwendet dieselben Anmeldeinformationen

Problem

So kann hypothetischer Benutzer X (ob ein Meatsack mit Excel oder IIS AppPool Identity) einige Ansichten und Code sehen. Es spielt keine Rolle, in welcher Datenbank sich diese Ansichten und der Code befinden, da userX sowieso in 3 Datenbanken eingerichtet ist.

Auf diese Weise verlieren Sie jedoch die Eigentumsverkettung.

Sagen wir WebDB.dbo.SomeProcAnrufe PrivateDB.dbo.SomeTable. UserX benötigt Berechtigungen für beide Objekte. Wenn dies verwendet wurde, OneDB.WebGUI.SomeProcwerden OneDB.dbo.SomeTablenur die OneDB.WebGUI.SomeProcerforderlichen Berechtigungen benötigt. Berechtigungen für referenzierte Objekte mit demselben Eigentümer werden nicht überprüft.

Hinweis: Ich habe die datenbankübergreifende Eigentumsverkettung nicht zu genau untersucht . Ich kenne nur ganz alte "Eigentumsverkettungen" gut

Nun haben Sie laut Kommentaren wirklich 2 Datenbanken, die kombiniert werden können. Nicht 3, was ursprünglich impliziert wurde. Zwischenprodukt und Bahn können jedoch kombiniert werden.

Die anderen "privaten" Datenbanken können möglicherweise kombiniert werden, aber das ist ein separates Problem. Unter dem unteren Link finden Sie eine ausführlichere Beschreibung von "einer Datenbank oder mehreren".

Lösung?

Wenn die zusätzlichen Datenbanken nur Codecontainer sind, sind Schemas eine bessere Idee.

Das hört sich so an, als hätten Sie "Database" verwendet, wo Sie "Schema" verwenden sollten (im Sinne von SQL Server, nicht im Sinne von MySQL). Ich hätte ein WebGUI-Schema, ein Hilfs- oder allgemeines Schema (um die Zwischendatenbank zu ersetzen) und ein Desktop-Schema. Auf diese Weise trennen Sie Berechtigungen basierend auf Clients und haben nur eine Datenbank

Mit einer Datenbank (zusätzlich zu "Eigentumsverkettung") können Sie auch indizierte Ansichten, SCHEMABINDING (ich verwende es immer) und solche berücksichtigen, die mit separaten Datenbanken nicht möglich sind

Weitere Informationen zu Schemata finden Sie in den folgenden Fragen:

• Schema-Design - Best Practices?
• Überbeanspruchung / korrekte Verwendung von Schemata?

Schließlich scheint es keinen Grund zu geben, separate Datenbanken basierend auf "Transaktionsintegrität nicht erforderlich" zu haben. Erklären Sie dies anhand der folgenden Frage: Entscheidungskriterien für die Verwendung eines Nicht-DBO-Schemas gegenüber einer neuen Datenbank

Die Antwort lautet: es kommt darauf an. Wenn der Zugriff auf die private Datenbank nicht über ein externes internes LAN (oder nur über ein VPN) erfolgt, erhöht dieses Schema die Sicherheit, da Personen, die die Anmeldeinformationen der Website verwenden, nur eingeschränkten Zugriff auf diesen privaten DB-Server haben (und mehr Arbeit haben werden) in Ihr internes Netzwerk - Zeit, die nützlich sein kann, um das Eindringen zu entdecken und die Lücke zu schließen).

Wenn nicht, fügt es meiner Meinung nach nichts außer Komplexität hinzu.

BEARBEITEN:

Scheint Ich habe Ihre Frage falsch verstanden, so lasst uns sehen , ob ich das jetzt richtig verstanden: die IntermDb ist eine leere Datenbank nur zu PrivateDB zu verbinden ODER es ist ein DB mit Blick / Verfahren seiner eigenen haben , die mit dem PrivateDB verbindet Daten abzurufen ?

Im ersten Fall WTF? Reiß es ab. Es ist wertlos, es sei denn, jemand möchte es überprüfen, um den Profilzugriff auf die PrivateDB auf eine entspannte Art und Weise zu überprüfen (und WebApp-Entwickler dazu zu bringen, härter zu arbeiten). SQL Profiler kann mit DB_ID filtern ...

Im zweiten Fall halte ich meine vorherige Antwort aufrecht.

BEARBEITEN: "Ich sehe immer noch nicht, wie sicherer dies ist, als die private Datenbank direkt mit der öffentlichen Datenbank zu verbinden, da alle 3 Datenbanken auf derselben SQL-Instanz und die für alle 3 Datenbanken verwendete Anmeldung gleich sind und nur darauf zugreifen können spezifische Ansichten und gespeicherte Prozeduren in der privaten Datenbank ".

Die Vermittlungs - Mittel haben , dass Invader würde in Ihrem Code graben , wissen die Existenz eines IntermDB - und haben Ihren Code zu graben darauf , dass existiert ein PrivateDB zu kennen.

Wenn Sie Ihre PrivateDB auf einen anderen internen Server Ihres Unternehmens-LAN / WAN stellen (falls möglich), kann dies dem Administrator ausreichend Zeit geben, um den Versuch einer Invasion zu erkennen und zu blockieren. Wenn Sie Synonyme verwenden, funktioniert dies reibungslos, da Sie sie nur im vorhandenen Code neu erstellen und an die richtige Stelle verschieben müssen.

Darüber hinaus haben Sie weitere Vorteile: Da der gesamte Code IntermDB passieren muss, um auf Daten in PrivateDB zuzugreifen, ist kein Entwickler versucht, ihn zu umgehen. Dieser Versuch kann in SQL Server Profiler problemlos als DB_ID der Anforderung von PrivateDb-Daten erkannt werden wäre WebAppDb.