SSDT: как защитить пароль, содержащийся в профиле публикации?

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

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

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

Несмотря на то, что я создал конкретный логин и пароль для развертывания, для меня это кажется незащищенным.

Есть ли обходной путь? Я могу думать только о замене пароля в командной строке msbuild на сервере непрерывной интеграции.

1 ответ

tl; dr версия

Аутентификация Windows - это предпочтительный безопасный способ подключения к вашему экземпляру SQL Server, и если это возможно, то рекомендуется использовать его для соединений.

Если используется проверка подлинности SQL, то по умолчанию в профилях публикации указано, что пароль не сохраняется. Для серверов сборки и других сценариев совместного доступа вам может потребоваться принять более низкие уровни безопасности (путем редактирования профиля публикации, чтобы добавить пароль или установить его как параметр в конфигурации сборки) или обойти его каким-либо другим способом (пользовательский script, который читает его из какого-либо секретного хранилища, такого как зашифрованное значение).

Длинная версия

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

Аутентификация SQL: Если вы посмотрите на профиль публикации (Open With... Xml Editor), вы увидите, что информация о пароле там фактически не хранится.

  • Если вы выберете "Сохранить пароль", у вас будет "Persist Security Info = True"; сохраненный в строке соединения, а не сам пароль.
  • При подключении к серверу/базе данных в SSDT с включенным "Сохранить пароль" информация о подключении зашифровывается и сохраняется в реестре в разделе "HKEY_CURRENT_USER\Software\Microsoft\SSDT\ConnectionStrings". Это должно присутствовать на машине для успешной публикации с использованием профиля публикации.
  • Следовательно, в командной среде каждый пользователь должен будет подключиться хотя бы один раз, прежде чем этот профиль публикации будет работать для них. Однако пароль будет безопасно зашифрован на пользовательских машинах.
  • Для сервера сборки ваши варианты более ограничены. Одна из возможностей заключается в том, чтобы вручную войти в систему как пользователь сервера сборки, а затем подключиться к базе данных, но это не очень масштабируемо. Чтобы избежать менее надежных опций, о которых вы упомянули, вам нужно будет реализовать свою собственную логику для надежного сохранения пароля. Вы можете посмотреть API защищенных данных, который можно использовать, чтобы сделать что-то похожее на то, что делает SSDT, но на уровне каждой машины, или использовать зашифрованный файл конфигурации.

Если вам нужно использовать проверку подлинности SQL, я думаю, что передача пароля в действие публикации, как часть конфигурации сборки, может быть "лучшим" способом в плане компромисса между легкостью разработки и безопасности. По крайней мере, вы можете ограничить, кто может просматривать и редактировать конфигурацию сборки в TFS, и обычные разработчики этого не видят.

licensed under cc by-sa 3.0 with attribution.