Использование Linked Server с настройкой безопасности
Очень часто администраторы баз данных сталкиваются с необходимостью связывания нескольких серверов, чтобы организовать сотрудникам доступы к более широкому спектру информации. Данная статья подробно описывает такую возможность в MS SQL при помощи Linked Server с соблюдением всех необходимых настроек безопасности.
Be made using the login’s current security context»
(«устанавливать с использованием текущего контекста безопасности имени для входа»)
Как правильно организовать доступ сотрудников организации к данным в условиях использования нескольких экземпляров СУБД MS SQL с помощью технологии LinkedServer, с windows аутентификацией пользователей на СУБД MS SQL, сохранив при этом права на доступы к конкретным данным конкретных баз данных (БД) на конкретных серверах? Как избежать создания промежуточных учетных записей (УЗ) с правами на LinkedServer и правами на удаленные БД, которые потеряют свою актуальность при изменении прав пользователя к одной из БД или схеме БД, или роли в БД?
Ответ, казалось бы, на поверхности, корпорация Microsoft предусмотрела такую схему работы. Но если мы просто выберем обсуждаемую настройку — то результат окажется нулевым. Мы увидим сообщение об ошибке ниже:
Почему так происходит, на каком этапе теряются данные о пользователе и откуда появляется anonymous LOGON, поможет понять изучение материалов о double HOP на MSDN.
Для решения же нашей задачи достаточно выполнить ряд условий и настроек, описанных ниже и этой опцией от Microsoft все-таки можно воспользоваться.
Итак, начнем:
Дано:
- домен MS Windows;
- 3 Экземпляра СУБД MS SQL;
- windows аутентификация пользователей на СУБД MS SQL.
Задача:
Обеспечить доступ пользователей к данным БД на всех экземплярах СУБД с помощью технологии LinkedServer.
Решение:
- Создадим в ActiveDirectory (AD) доменную УЗ domain\master_SQL. Под этой УЗ будут стартовать все службы MS SQL всех наших экземпляров СУБД;
- Настроим старт служб MS SQL от имени этой УЗ на каждом сервере;
- Настроим ServicePrincipalName (SPN) для УЗ domain\master_SQL:
Выполним в командной строке
где:
- S ключ для команды setSPN на создание SPN;
- mssqlsvc/SQLServer1 – служба MS SQL на сервере SQLServer1;
- 1433 – порт для MS SQL;
- domain\master_SQL – доменная УЗ под которой стартуют службы MS SQL.
4. В Active Directory — Пользователи и компьютеры, в свойствах учетной записи domain\master_SQL, во вкладке «делегирование» выполнить настройку согласно рисунку ниже:
5. Настроим Distributed Transaction Coordinator (DTC) на серверах Windows, на которых развернуты экземпляры СУБД MS SQL.
На сервере, на котором развернут наш MS SQL выполним следующую настройку: Control Panel > Administrative Tools > Component Services > Computers > My Computer > Distributed Transaction Coordinator.
На локальном DTC выбираем «свойства» идем на вкладку безопасность и отмечаем следующие пункты:
- включить доступ к сети DTC;
- разрешить удаленные клиенты;
- разрешить удаленное Администрирование;
- разрешить входящие;
- разрешить исходящие;
- не требуется проверка подлинности
Нажать ОК. Служба DTS будет перезапущена.
6. Создаем Linked Server с настройкой безопасности — «Be made using the login’s current security context» («устанавливать с использованием текущего контекста безопасности имени для входа») на каждом экземпляре СУБД для каждого экземпляра СУБД.
Таким образом, мы обеспечили возможность для сотрудников с windows аутентификацией пользователя на СУБД MS SQL использовать Linked Server с настройкой «Be made using the login’s current security context» («устанавливать с использованием текущего контекста безопасности имени для входа»). Кто-то может возразить, что проблемы не было бы используй мы аутентификацию для входа SQL. Однако для повышения уровня безопасности доступа к данным, аудита действий пользователя Microsoft рекомендует использовать windows аутентификацию пользователя на СУБД MS SQL.