SQL, Анализ данных

Использование Linked Server с настройкой безопасности

Время прочтения: 3 мин.

«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.

Решение:

  1. Создадим в ActiveDirectory (AD) доменную УЗ DOMAIN\MASTER_SQL. Под этой УЗ будут стартовать все службы MS SQL всех наших экземпляров СУБД;
  2. Настроим старт служб MS SQL от имени этой УЗ на каждом сервере;
  3. Настроим ServicePrincipalName (SPN) для УЗ DOMAIN\MASTER_SQL:

Выполним в командной строке

setSPN –S MSSQLSvc/SQLServer1:1433
setSPN –S MSSQLSvc/SQLServer1 DOMAIN\MASTER_SQL

где:

  •  S ключ для команды setSPN на создание SPN;
  • MSSQLSvc/SQLServer1 – служба MS SQL на сервере SQLServer1;
  • 1433 – порт для MS SQL;
  • DOMAIN\MASTER_SQL – доменная УЗ под которой стартуют службы MS SQL.
  1. В Active Directory — Пользователи и компьютеры, в свойствах учетной записи DOMAIN\MASTER_SQL, во вкладке «делегирование» выполнить настройку согласно рисунку ниже:
  1. Настроим Distributed Transaction Coordinator (DTC) на серверах Windows, на которых развернуты экземпляры СУБД MS SQL.

На сервере, на котором развернут наш MS SQL выполним следующую настройку: Control Panel > Administrative Tools > Component Services > Computers > My Computer > Distributed Transaction Coordinator.

На локальном DTC выбираем «свойства» идем на вкладку безопасность и отмечаем следующие пункты:

  • включить доступ к сети DTC;
  •  разрешить удаленные клиенты;
  • разрешить удаленное Администрирование;
  •  разрешить входящие;
  •  разрешить исходящие;
  • не требуется проверка подлинности

Нажать ОК. Служба DTS будет перезапущена.

  1. Создаем 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.

Советуем почитать