Безопаснее ли проходить третью базу данных, чтобы соединить две базы данных, используя один и тот же логин?

У нас есть следующие настройки:

• Многопрофильная база данных, содержащая личные данные, которые используются настольным программным обеспечением
• Веб-база данных для общедоступного веб-сайта, которому требуются данные из частных баз данных.
• Промежуточная база данных, которая содержит несколько представлений и хранимых процедур, которые извлекают данные из частных баз данных.

В настоящее время веб-сайт выполняет вход в веб-базу данных, а веб-база данных подключается к промежуточной базе данных для извлечения данных или выполнения хранимых процедур в производственных базах данных. Все базы данных находятся в одном экземпляре SQL, и весь процесс использует одну и ту же учетную запись пользователя.

Учетная запись пользователя имеет полный доступ к веб-базе данных и промежуточной базе данных, но может иметь доступ только к определенным представлениям, хранимым процедурам и частной базе данных.

Действительно ли это безопаснее, чем просто подключать общедоступную базу данных напрямую к частной?

Кажется, что промежуточная база данных существует только для того, чтобы усложнить ситуацию, поскольку один и тот же логин используется для доступа к данным во всех базах данных, и он уже ограничен только теми представлениями / SP, которые ему необходимы в частных базах данных. Я надеюсь удалить это.

Здесь выскакивает одна вещь:

Весь процесс использует один и тот же набор учетных данных

проблема

Таким образом, гипотетический пользователь X (будь то какой-то мясной мешок с использованием Excel или IIS AppPool Identity) может видеть некоторые представления и код. Неважно, в какой базе данных эти представления и код, потому что userX настроен на 3 базы данных.

Тем не менее, вы теряете цепочку владения таким образом.

Допустим, WebDB.dbo.SomeProcзвонки PrivateDB.dbo.SomeTable. UserX требует разрешения для обоих объектов. Если это OneDB.WebGUI.SomeProcиспользуется, OneDB.dbo.SomeTableто только OneDB.WebGUI.SomeProcразрешения. Права доступа к ссылочным объектам с одним и тем же владельцем не проверяются.

Примечание: я не слишком внимательно изучал цепочку владения несколькими базами данных . Я знаю только простую старую «цепочку владения» хорошо

Теперь, согласно комментариям, у вас действительно есть две базы данных, которые можно объединить. Не 3, который изначально подразумевался. Тем не менее, промежуточное звено и сеть могут быть объединены.

Другие «частные» базы данных могут быть объединены, но это будет отдельной проблемой. Смотрите нижнюю ссылку для более полного обсуждения "одна база данных или много"

Решение?

Если дополнительные базы данных являются только контейнерами кода, тогда лучше использовать схемы.

Похоже, вы использовали «База данных», где вы должны использовать «Схема» (в смысле SQL Server, а не в MySQL). Я хотел бы иметь схему WebGUI, вспомогательную или общую схему (для замены промежуточной базы данных) и схему рабочего стола. Таким образом, вы разделяете разрешения на основе клиентов и имеете только одну базу данных

С одной базой данных (в дополнение к «цепочке владения») вы также можете начать рассматривать индексированные представления, SCHEMABINDING (я всегда использую) и такие, которые не могут быть сделаны с отдельными базами

Подробнее о схемах смотрите в следующих вопросах:

• Схема проектирования - лучшие практики?
• За использование / правильное использование схем?

Наконец, нет никакой причины иметь отдельные базы данных, основанные на «целостности транзакций не требуется». См. Этот вопрос, чтобы объяснить это: Критерии принятия решения о том, когда использовать схему не-dbo против новой базы данных

Ответ: это зависит. Если доступ к частной базе данных не осуществляется извне внутренней ЛВС (или только через VPN), эта схема повышает безопасность, поскольку кто-то, использующий учетные данные веб-сайта, будет иметь только ограниченный доступ к этому частному серверу БД (и у него будет еще немного работы, чтобы получить во внутреннюю сеть - время, которое может пригодиться для обнаружения вторжения и закрытия дыры).

Если нет, я не думаю, что это добавляет ничего, кроме сложности.

РЕДАКТИРОВАТЬ:

Кажется, я неправильно понял ваш вопрос, поэтому давайте посмотрим, правильно ли я понял сейчас: IntermDb - это пустая база данных, предназначенная только для подключения к PrivateDB, ИЛИ это БД, которая имеет собственные представления / процедуры, которая подключается к PrivateDB для извлечения данных. ?

В первом случае WTF? Сорви это. Это бесполезно, если только кто-то не захочет проверить его, чтобы профилировать доступ к PrivateDB более ленивым способом (и заставить разработчиков WebApp работать усерднее). SQL Profiler может фильтровать, используя DB_ID ...

Во втором случае я поддерживаю свой предыдущий ответ.

РЕДАКТИРОВАТЬ: «Я до сих пор не понимаю, как это более безопасно, чем подключение частной базы данных напрямую к общедоступной базе данных, поскольку все 3 базы данных в одном экземпляре SQL и логин, используемый для всех 3 баз данных, одинаковы и могут получить доступ только к конкретные представления и хранимые процедуры в частном БД в любом случае ".

Наличие посредника означает, что захватчик должен будет копаться в вашем коде, чтобы узнать о существовании IntermDB, и он должен копать в нем ваш код, чтобы узнать, что существует PrivateDB.

Если вы разместите свою PrivateDB на другом сервере, внутреннем для вашей организации LAN / WAN (если это возможно), это может дать администратору достаточно времени, чтобы обнаружить и заблокировать попытку вторжения. Если вы используете синонимы, этот шаг будет плавным, поскольку все, что у вас есть, - это перестроить их в существующий код и перейти в нужное место.

Кроме того, вы получаете и другие преимущества: поскольку весь код должен проходить через IntermDB для доступа к данным в PrivateDB, ни у одного разработчика не возникнет соблазн попытаться обойти его - и эту попытку можно легко обнаружить на SQL Server Profiler как DB_ID запроса данных PrivateDb. будет WebAppDb.