3

我想在 Jenkins 中创建一个发布任务来自动发布我的数据库更改以及我的应用程序。

如果我理解正确，通常的做法是创建一个发布配置文件，其中包含数据库名称以及用于部署的帐户的帐户（登录名和密码）。

这意味着部署帐户的用户名和密码将以明文形式存储在每台开发人员计算机以及版本控制服务器和持续集成服务器上。

尽管我为部署创建了特定的登录名和密码，但对我来说似乎很不安全。

有解决方法吗？我只能想到在持续集成服务器上的 msbuild 命令行中替换密码。

4

1 回答 1

6

tl;博士版

Windows 身份验证是连接到 SQL Server 实例的首选安全方法，如果可以使用它，则建议将其用于连接。

如果使用 SQL 身份验证，则发布配置文件中的默认设置是不保存密码。对于构建服务器和其他共享配置文件场景，您可能需要接受较低级别的安全性（通过编辑发布配置文件以添加密码，或将其设置为构建配置中的参数）或以其他方式解决它（自定义脚本从某种秘密存储中读取它，例如加密值）。

长版

Windows 身份验证：如果可能，请使用 Windows 身份验证，根据需要向需要它的用户授予权限。对于持续集成场景，您需要为构建服务器在其下执行的帐户授予适当的权限 - 完整的详细信息在SSDT 博客上最近的白皮书中。

SQL 身份验证：如果您查看发布配置文件（打开方式... Xml 编辑器），您会发现密码信息实际上并未存储在那里。

  • 如果您选择“保存密码”，您将拥有“Persist Security Info=True;” 存储在连接字符串中，而不是密码本身。
  • 在启用“保存密码”的情况下与 SSDT 中的服务器/数据库建立连接时，连接信息将被加密并存储在注册表中的“HKEY_CURRENT_USER\Software\Microsoft\SSDT\ConnectionStrings”下。这必须存在于机器上才能使用发布配置文件成功发布。
  • 因此，在团队环境中，每个用户都需要至少连接一次，然后发布配置文件才能为他们工作。但是，密码将在用户计算机上安全加密。
  • 对于构建服务器，您的选择更加有限。一种可能性是以构建服务器用户身份手动登录，然后连接到数据库，但这不是很可扩展。为了避免您提到的不太安全的选项，您需要实现自己的逻辑来安全地保存密码。您可以查看受保护的数据 API，该 API 可用于执行与 SSDT 类似但在每台机器级别执行的操作，或者使用加密的配置文件。

如果您必须使用 SQL 身份验证，我认为将密码作为构建配置的一部分传递给发布操作可能是在易于开发和安全性之间进行权衡的“最佳”方式。至少通过这种方式，您可以限制谁可以查看和编辑 TFS 中的构建配置，而普通开发人员将看不到它。

于 2014-08-06T02:32:27.520 回答