Почему связанные серверы будут запрещены?

Question

Я работаю в корпоративной среде, где создание связанных серверов абсолютно запрещено. Я спросил администратора базы данных о причине, и единственный ответ, который я когда-либо получал, это «Это политика». Поэтому мне приходится писать и использовать пакеты служб SSIS для перемещения данных между базами данных, когда возникает такая необходимость.

Может кто-нибудь сказать мне, что могло быть причиной создания такой политики? Мне это кажется неоправданным.

Answer 1

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

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

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

Answer 2

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

Answer 3

Вот альтернатива более вероятным объяснениям в других ответах. Политика может быть одиноким выжившим из школы мысли Сервис-ориентированная архитектура . Который заявил, что:

Сервис-ориентация направлена ​​на свободный сцепление услуг

Связанные серверы являются низкоуровневыми и прочно связанными, и астронавт архитектуры может из-за этого запретить связанные серверы.

Один из способов «исправить» эту политику - убедить ваших бизнес-клиентов в том, что у вас есть хорошее и надежное решение их проблемы; но для этого абсолютно необходимы связанные серверы. Деловые люди будут общаться с администраторами баз данных, и есть большая вероятность, что администратор базы данных согласится на пробную версию связанного сервера. Чтобы это сработало, поговорите с администратором базы данных с самым сильным противником связанных серверов. Администраторы баз данных могут спорить с разработчиками, но они быстро уступают бизнесу.

Пробный период будет концом политики. Связанные серверы работают, а SOA - нет.

P.S. В Нидерландах нам повезло: на голландском языке SOA означает болезнь, передаваемую половым путем, поэтому SOA silver bullet fantasy своего рода пролетела мимо:

Answer 4

Simple. Кто-то решил, что он принадлежит к «слишком жесткой» корзине. Также есть безопасность (доступ к одному серверу через бэкдор в другом) и стабильность (сервер A выходит из строя и забирает сервер B).

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

Вы всегда можете спросить, где прописана политика. Скорее всего, формальной политики на самом деле нет.

Answer 5

Обычно проблема связана с отображениями входа в систему.

Если вы отображаете:

• «Любой локальный для конкретного удаленного», тогда любой может использовать связанный сервер

• «определенный локальный для конкретного удаленного», тогда локальному требуется запись для текущего пользователя в sys.server_principals, что означает, что вы не можете ограничиться группой NT: вы должны перечислять пользователей отдельно (что наверное не в полисе)

• «использовать себя» (это вариант «от конкретного локального к удаленному конкретному»), тогда мой доверенный токен входа «domain \ bob» используется для удаленного входа. Для этого необходимо, чтобы локальный сервер был настроен для делегирования, а имя участника-службы настроено в AD.

Также:

• Я видел случаи, когда удаленный вход в систему имеет права «syadmin», поскольку он не управляется администраторами баз данных или управляется другой группой. Это означает, что все SQL-серверы, как правило, скомпрометированы.

Вы можете использовать OPENDATASOURCE, но для этого требуется доступ по запросу. Что может быть разрешено вместо статического связанного сервера.

Используются правильно, они в порядке, но у них есть ограничения в отображении логинов. Так что проще сказать нет.

Мы используем их здесь, FWIW.