29 марта 2023

MS SQL Server. Управление контекстом безопасности подключения к связанным серверам

    Механизм связанных серверов MS SQL Server позволяет реализовать распределенные базы данных, которые работают с данными в других базах данных. "Связаться" можно с любым источником данных, для которого существует возможность подключения к нему с использованием OLE DB. Есть два шага обеспечения безопасности при подключении к удаленной базе данных связанного сервера:
  1. сопоставить имена пользователей локального сервера MS SQL Server с именами пользователей удаленного сервера;
  2. указать, как связанный сервер должен обрабатывать подключение пользователей, имена которых не сопоставлены.
Оба эти шага из T-SQL выполняются с помощью процедуры sp_addlinkedsrvlogin. Она создает или обновляет сопоставление между учетными записями пользователей локального и удаленного серверов. Название процедуры намекает на шаг с сопоставлением имен пользователей, но определенные комбинации ее параметров позволяют управлять подключением всех не сопоставленных пользователей.

    Для примера создадим связанный сервер "test", который будет связан с базой данных Oracle прописанной в tnsnames.ora как "XYZ", и сопоставим для него пользователя MS SQL Server "mssql_login" с пользователем Oracle "ora_user":

exec master.dbo.sp_addlinkedserver @server = N'test', @srvproduct=N'Oracle', @provider=N'OraOLEDB.Oracle', @datasrc=N'XYZ'
go
exec master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'test',@useself=N'False',@locallogin='mssql_login',@rmtuser=N'ora_user',@rmtpassword=N'ora_user_password'
go
Результат работы скрипта можно увидеть в SQL Server Management Studio. В свойствах связанного сервера нас интересует закладка "Security" ("Безопасность").
Linked server properties (Свойства связанного сервера)
В верхней части диалога мы видим таблицу со списком сопоставленных имен, а в нижней способ идентификации пользователей, имена которых не сопоставлены. По умолчанию он имеет значение "Be made using the login's current security context" ("Подключаться с использованием текущего контекста безопасности имени входа"). С этим способом идентификация не сопоставленных пользователей при подключении к удаленной базе данных зависит от способа их подключения к локальному серверу:
  • если оно установлено с использованием проверки подлинности SQL Server, то для подключения к удаленному серверу будут использоваться имя и пароль подключившегося пользователя (поэтому на удаленном сервере должны существовать учетные данные пользователя с тем же именем и паролем);
  • если оно установлено с использованием проверки подлинности Windows, то для подключения к удаленному серверу будут использоваться учетные данные Windows (учетные данные домена).
На этот вариант идентификации не сопоставленных пользователей можно переключиться, выполнив команду:
exec master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'test',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL

    Второй вариант "Be made using this security context" ("Подключаться с использованием данного контекста безопасности") – не сопоставленные пользователи локального сервера подключаются к удаленной базе данных под одной учетной записью пользователя удаленного сервера.

exec master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'test',@useself=N'False',@locallogin=NULL,@rmtuser=N'ora_user',@rmtpassword=N'ora_user_password'

    Третий вариант "Be made without using a security context" ("Подключаться без использования контекста безопасности") – не сопоставленные пользователи локального сервера подключаются к удаленной базе данных без использования контекста безопасности. Какой-то "мутный" вариант. Гость?

exec master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'test',@useself=N'False',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL

    Четвертый вариант "Not be made" ("Не подключаться") – запрет на подключение к удаленной базе данных всем не сопоставленным пользователям. Так как генерация скрипта создания для существующего связанного сервера в SQL Server Management Studio не показывает полную реализацию этого варианта, то над ней пришлось некоторое время подумать. Решение подсказал параметр @locallogin=NULL, который мы указывали в первых трех вариантах. Оказывается, что при вызове sp_addlinkedserver создается сопоставление для локального пользователя с именем равным NULL, которое потом используется для управления подключением не сопоставленных пользователей. Значит, что для переключения на "Not be made" необходимо просто удалить созданное по умолчанию сопоставление. Для этого воспользуемся процедурой sp_droplinkedsrvlogin:

exec master.dbo.sp_droplinkedsrvlogin @rmtsrvname=N'test', @locallogin=NULL

    Вот такое "костыльное" решение от Microsoft для настройки подключения к связанному серверу пользователями с не сопоставленными именами. На месте разработчиков этого функционала, я бы скрыл работу с пользователем по умолчанию добавив еще одну процедуру с двумя параметрами (сервер и вариант подключения):

exec master.dbo.sp_defaultlinkedsrvlogin @rmtsrvname=N'test', @connect=X
Или это синтаксический сахар?

Комментариев нет:

Отправить комментарий