Безопасное хранение паролей в SQL Server для использования с динамическими источниками данных — службы SSIS

Мы активно используем динамические источники данных. Мы извлекаем имя сервера и имена баз данных из таблицы в базе данных SQL Server. Пакет перебирает имена серверов и имена баз данных и выполняется один раз для каждого сервера, для каждой базы данных.

Затем эти значения помещаются в поля ServerName и InitalCatalog динамического соединения. Пользователь и пароль предопределены (и, следовательно, одинаковы для каждого соединения). Я также хотел бы ввести пользователя + пароль из таблицы, но тогда мне нужно хранить пароли в виде открытого текста в этой таблице.

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

Все предложения по решению этой проблемы (например, с использованием различных подходов) очень ценятся!


person Henrov    schedule 23.04.2015    source источник
comment
У вас есть некоторые мысли по этому поводу в вопросе stackoverflow.com/questions/19845414/   -  person Ramón Gil Moreno    schedule 23.04.2015
comment
Нельзя ли сделать для этого специального пользователя и дать соответствующие права на каждом сервере. Вы даже можете создать для него прокси-аккаунт ssis, и вам не придется нигде раскрывать его пароль.   -  person Ako    schedule 23.04.2015
comment
@Ako: не могли бы вы рассказать об этом подробнее? Единственное соединение между машиной, на которой выполняется пакет служб SSIS, и серверами SQL (смесь SQL в виртуальных машинах и Azure SQL) — это соединение sql. Ни одна из машин не подключена к сети. Как мне тогда настроить «учетную запись poxy»? Звучит очень интересно.   -  person Henrov    schedule 24.04.2015
comment
Поэтому, когда вы обычно используете встроенную безопасность, задание попытается выполнить шаг под учетной записью агента SQL, а это не то, что вам нужно. Учетная запись-посредник заменяет учетные данные для учетной записи агента SQL (msdn.microsoft. com/en-us/library/ms175834.aspx), в этом случае тоже бесполезно. Я помню, что в Windows 2000 мы использовали трюк, создавая одинаковые локальные учетные записи с одинаковыми именами пользователей и паролями на всех серверах, чтобы обойти ограничение SSO, но я не знаю, работает ли это до сих пор.   -  person Ako    schedule 24.04.2015
comment
@Ako Можете ли вы оставить этот комментарий в качестве ответа? Так что я могу отдать вам должное, где это должно быть?   -  person Henrov    schedule 02.12.2018


Ответы (2)


Да, вы можете зашифровать/расшифровать столбец. См. пошаговое руководство Microsoft здесь:

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/encrypt-a-column-of-data?view=sql-server-2017

Лучше всего создать представление, которое расшифровывает столбец, а затем предоставить доступ на уровне пользователя (т. е. SELECT, ALTER, INSERT, UPDATE и т. д.) к представлению только потому, что представление должно иметь симметричный ключ для расшифровки данных. Раскрытие ключа может быть уязвимостью в системе безопасности, поэтому вы хотите, чтобы он был максимально заблокирован. Представление с ограниченным доступом пользователей — это лучшее место, где можно раскрыть ключ (если когда-либо есть хорошее место для раскрытия ключа, которого нет).

Но Ако прав. Используйте встроенную безопасность.

person J Weezy    schedule 05.12.2018

Предпочтительное решение — продолжать использовать встроенную систему безопасности.

Обычно задание попытается выполнить шаг под учетной записью агента SQL, а это не то, что вам нужно.

Учетная запись-прокси заменяет учетные данные для учетной записи агента SQL (msdn.microsoft.com/en-us/library/ms175834.aspx), что также бесполезно в этом случае.

Я помню, что в Windows 2000 мы использовали трюк, создав одинаковые локальные учетные записи с одинаковым именем пользователя и паролем на всех серверах, чтобы обойти ограничение SSO, возможно, это сработает в вашей ситуации.

person Ako    schedule 05.12.2018