Czy bezpieczniej jest przejść przez trzecią bazę danych, aby połączyć dwie bazy danych przy użyciu tego samego loginu?

Mamy następującą konfigurację:

• Wielokrotna produkcyjna baza danych zawierająca prywatne dane, z których korzysta oprogramowanie komputerowe
• Internetowa baza danych publicznej witryny internetowej, która potrzebuje danych z prywatnych baz danych
• Pośrednia baza danych, która zawiera kilka widoków i procedur przechowywanych, które pobierają dane z prywatnych baz danych

Obecnie witryna loguje się do internetowej bazy danych, a internetowa baza danych łączy się z pośrednią bazą danych w celu pobrania danych lub wykonania procedur przechowywanych w produkcyjnych bazach danych. Wszystkie bazy danych znajdują się w tej samej instancji SQL, a cały proces korzysta z tego samego konta użytkownika.

Konto użytkownika ma pełny dostęp do internetowej bazy danych i pośredniej bazy danych, ale może uzyskiwać dostęp tylko do określonych widoków i procedur przechowywanych oraz prywatnej bazy danych

Czy to naprawdę jest bezpieczniejsze niż zwykłe połączenie publicznej bazy danych bezpośrednio z prywatnymi?

Wygląda na to, że pośrednia baza danych jest tylko w celu skomplikowania rzeczy, ponieważ ten sam login służy do uzyskiwania dostępu do danych we wszystkich bazach danych i jest już ograniczony tylko do widoków / SP, których potrzebuje w prywatnych bazach danych. Mam nadzieję go usunąć.

Wyskakuje tutaj jedna rzecz:

Cały proces wykorzystuje ten sam zestaw danych logowania

Problem

Tak więc hipotetyczny użytkownik X (niezależnie od tego, czy jakiś mięsożerca używa Excela, czy też IIS AppPool Identity) widzi niektóre widoki i kod. Nie ma znaczenia, w jakiej bazie danych znajdują się te widoki i kod, ponieważ userX jest ustawiony w 3 bazach danych.

Jednak tracisz takie łańcuchy własności.

Powiedzmy, że WebDB.dbo.SomeProcdzwonisz PrivateDB.dbo.SomeTable. UserX wymaga uprawnień do obu obiektów. Jeśli tak byłoOneDB.WebGUI.SomeProc używane, OneDB.dbo.SomeTabletylko OneDB.WebGUI.SomeProcuprawnienia wymagają uprawnień. Uprawnienia do obiektów odniesienia z tym samym właścicielem nie są sprawdzane.

Uwaga: nie przyjrzałem się zbyt głęboko łańcuchowi własności między bazami danych . Dobrze znam tylko zwykłe stare „łańcuchy własności”

Teraz, zgodnie z komentarzami, naprawdę masz 2 bazy danych, które można łączyć. Nie 3, co pierwotnie sugerowano. Można jednak łączyć półprodukt i wstęgę.

Inne „prywatne” bazy danych można połączyć, ale będzie to osobny problem. Zobacz dolny link, aby uzyskać pełniejszą dyskusję na temat „jednej bazy danych lub wielu”

Rozwiązanie?

Jeśli dodatkowe bazy danych są tylko kontenerami kodu, schematy są lepszym pomysłem.

Brzmi to tak, jakbyś użył „Bazy danych”, w której powinieneś użyć „Schematu” (w sensie SQL Server, a nie MySQL). Miałbym schemat WebGUI, schemat pomocnika lub wspólny (w celu zastąpienia pośredniej bazy danych) i schemat pulpitu. W ten sposób rozdzielasz uprawnienia na podstawie klientów i masz tylko jedną bazę danych

Za pomocą jednej bazy danych (oprócz „tworzenia powiązań własnościowych”) możesz również zacząć rozważać indeksowane widoki, SCHEMABINDING (zawsze go używam) i takie, których nie da się zrobić z oddzielnymi bazami danych

Aby uzyskać więcej informacji na temat schematów, zobacz następujące pytania:

• Projektowanie schematu - najlepsze praktyki?
• Nadużywanie / prawidłowe używanie schematów?

Wreszcie, wydaje się, że nie ma powodu, aby mieć osobne bazy danych oparte na „nie wymaganej integralności transakcyjnej”. Zobacz to pytanie, aby to wyjaśnić: Kryteria decyzyjne dotyczące użycia schematu innego niż dbo w porównaniu z nową bazą danych

Odpowiedź brzmi: to zależy. Jeśli dostęp do prywatnej bazy danych nie jest uzyskiwany z zewnętrznej wewnętrznej sieci LAN (lub tylko przez VPN), ten schemat zwiększa bezpieczeństwo, ponieważ osoba korzystająca z poświadczeń witryny sieci Web miałaby po prostu ograniczony dostęp do tego prywatnego serwera DB (i będzie miał trochę więcej pracy, aby uzyskać do wewnętrznej sieci - czas, który może być przydatny w wykrywaniu włamań i zamykaniu dziury).

Jeśli nie, to nie sądzę, żeby to dodawało niczego oprócz złożoności.

EDYTOWAĆ:

Wygląda na to, że źle odczytałem twoje pytanie, więc sprawdźmy, czy teraz zrozumiałem poprawnie: IntermDb to pusta baza danych, aby połączyć się z PrivateDB LUB jest to która ma własne widoki / procedurę, która łączy się z PrivateDB w celu pobrania danych ?

W pierwszym przypadku WTF? Oderwij to. Jest to bezwartościowe, chyba że ktoś chce go zrewidować, aby profilować dostęp do PrivateDB w bardziej leniwy sposób (i zmuszać programistów WebApp do cięższej pracy). SQL Profiler może filtrować za pomocą DB_ID ...

W drugim przypadku podtrzymuję moją poprzednią odpowiedź.

EDYCJA: „Nadal nie widzę, w jaki sposób jest to bardziej bezpieczne niż podłączenie prywatnej bazy danych bezpośrednio do publicznej bazy danych, ponieważ wszystkie 3 bazy danych w tej samej instancji SQL i dane logowania używane dla wszystkich 3 baz danych są takie same i mogą uzyskać dostęp tylko w każdym razie konkretne widoki i procedury przechowywane w prywatnej bazie danych ".

Posiadanie pośrednika oznacza, że ​​najeźdźca musiałby kopać w twoim kodzie znając istnienie IntermDB - i musiałby wykopać na nim swój kod, aby wiedzieć, że istnieje PrivateDB.

Jeśli umieścisz PrivateDB na innym serwerze wewnętrznym w Twojej sieci LAN / WAN (jeśli to możliwe), może dać administratorowi wystarczająco dużo czasu na wykrycie i zablokowanie próby inwazji. Jeśli używasz synonimów, ten ruch jest płynny, ponieważ wszystko, co masz, to odbudować je do istniejącego kodu i przejść we właściwe miejsce.

Ponadto zyskujesz inne zalety: ponieważ cały kod musi przejść przez IntermDB, aby uzyskać dostęp do danych w PrivateDB, żaden programista nie miałby pokusy, aby spróbować to ominąć - i tę próbę można łatwo zauważyć w SQL Server Profiler jako DB_ID żądania danych PrivateDb byłby WebAppDb.