pncsoares Asked: 2019-04-27 16:25:06 +0800 CST2019-04-27 16:25:06 +0800 CST 2019-04-27 16:25:06 +0800 CST EXE 或 DLL 格式的 SQL 数据库脚本 772 我使用 SQL Server 2016，我需要将某些版本中生成的脚本发送给我们的客户，以便他们可以在 UAT 和 Production 中安装包。我想发送 DLL 或 EXE 格式的脚本，这样他们就看不到内容了。可能吗？我需要一些第三方应用程序吗？如果有，是哪些？ sql-server encryption 2 个回答 Voted Best Answer David Spillett 2019-04-29T04:36:51+08:002019-04-29T04:36:51+08:00 将生成的脚本发送给我们的客户……他们看不到他们的内容。 这在技术上是不可能的，但可能会根据您的威胁模型来实施。问题是生成的可分发文件必须能够解压/解码/解密脚本，以便将它们提交给 SQL Server，因此它必须包含所有必需的算法和密钥。 如果您的威胁模型涉及试图阻止坚定的窥探者（可能是竞争对手，或者是希望找到尚未修补的安装仍然容易受到攻击的漏洞的黑帽）查看代码，那么使用简单的可分发文件是不可能的。无论您添加多少层，他们都可以通过分析可分发文件来取消选择它们。 其次，如果你把事情搞得够麻烦，以至于他们不想这样做，他们还有另一条检查途径：他们可以拦截与 SQL Server 的通信，并在代码流过时观察代码。是的，TDS 流通常是加密的，但他们正在针对他们的 SQL 服务器运行程序包，以便控制客户端和服务器，因此可以控制（并因此出于他们自己的目的而破坏）加密。第三，他们总是可以只查看数据库，并将当前备份与补丁前备份进行比较，如果这会使更改更加明显，唯一的解决方法是让您托管数据库，也许在 SaaS 中运行您的产品-只有方式。 如果您担心的仅仅是更多的机会主义窥探，那么那里有许多安装打包程序[1]支持创建自解压可执行文件，这些文件将运行存档中的程序以运行存档中的脚本并尽可能地清理之后可能，并支持加密或以其他方式混淆传输中的内容。 [1] 我不会提到具体的，因为有很多（免费的、免费的、开源的和商业的），我对任何具体的了解都不够权威地比较它们，我对你的开发和生产环境一无所知（其他比它们包括 SQL Server），并且由于其他地方详细解释的原因，不鼓励在 StackExchange 上购物/推荐问题/答案。 不过，我建议不要为此目的使用此类工具：您正在添加一层不必要的复杂性，并且可能会使调试安装问题对您和您的客户来说更成问题（这看起来不太好） . 如果您确实使用此类产品，那么这样做是为了方便：为您的客户将安装作为一个（或至少最少的）步骤过程，以减少人为错误的风险，而不是作为一种安全措施。 如果您担心的是更多的“人为因素”，例如代码注释中的糟糕语言或其他尴尬源，那么问题就是纪律和缺乏代码审查，而不是分发安全性，这需要在您的过程中尽早解决。 我需要在某些版本中发送生成的脚本 作为旁注：如果您的意思是您正在从 SQL Server 生成脚本以便分发，那么您可能需要改进您的开发过程。您应该能够从源代码控制构建包括升级包在内的所有内容，而不是从您的开发数据库生成脚本。这可能需要付出一些努力才能顺利运行，但它可以使您免于将来出现一系列故障类型。 Dat Nguyen 2019-04-27T18:27:18+08:002019-04-27T18:27:18+08:00 我建议自己构建一个 shell 程序。您需要将 sql 脚本硬编码到其中并将其构建为 exe 文件。因此，然后向客户提供运行命令。 或者在 sql server 中使用数据层的另一种方法。MSDN：https ://learn.microsoft.com/en-us/sql/relational-databases/data-tier-applications/data-tier-applications
这在技术上是不可能的，但可能会根据您的威胁模型来实施。问题是生成的可分发文件必须能够解压/解码/解密脚本，以便将它们提交给 SQL Server，因此它必须包含所有必需的算法和密钥。
如果您的威胁模型涉及试图阻止坚定的窥探者（可能是竞争对手，或者是希望找到尚未修补的安装仍然容易受到攻击的漏洞的黑帽）查看代码，那么使用简单的可分发文件是不可能的。无论您添加多少层，他们都可以通过分析可分发文件来取消选择它们。
其次，如果你把事情搞得够麻烦，以至于他们不想这样做，他们还有另一条检查途径：他们可以拦截与 SQL Server 的通信，并在代码流过时观察代码。是的，TDS 流通常是加密的，但他们正在针对他们的 SQL 服务器运行程序包，以便控制客户端和服务器，因此可以控制（并因此出于他们自己的目的而破坏）加密。第三，他们总是可以只查看数据库，并将当前备份与补丁前备份进行比较，如果这会使更改更加明显，唯一的解决方法是让您托管数据库，也许在 SaaS 中运行您的产品-只有方式。
如果您担心的仅仅是更多的机会主义窥探，那么那里有许多安装打包程序[1]支持创建自解压可执行文件，这些文件将运行存档中的程序以运行存档中的脚本并尽可能地清理之后可能，并支持加密或以其他方式混淆传输中的内容。
[1] 我不会提到具体的，因为有很多（免费的、免费的、开源的和商业的），我对任何具体的了解都不够权威地比较它们，我对你的开发和生产环境一无所知（其他比它们包括 SQL Server），并且由于其他地方详细解释的原因，不鼓励在 StackExchange 上购物/推荐问题/答案。
不过，我建议不要为此目的使用此类工具：您正在添加一层不必要的复杂性，并且可能会使调试安装问题对您和您的客户来说更成问题（这看起来不太好） .
如果您确实使用此类产品，那么这样做是为了方便：为您的客户将安装作为一个（或至少最少的）步骤过程，以减少人为错误的风险，而不是作为一种安全措施。
如果您担心的是更多的“人为因素”，例如代码注释中的糟糕语言或其他尴尬源，那么问题就是纪律和缺乏代码审查，而不是分发安全性，这需要在您的过程中尽早解决。
作为旁注：如果您的意思是您正在从 SQL Server 生成脚本以便分发，那么您可能需要改进您的开发过程。您应该能够从源代码控制构建包括升级包在内的所有内容，而不是从您的开发数据库生成脚本。这可能需要付出一些努力才能顺利运行，但它可以使您免于将来出现一系列故障类型。
我建议自己构建一个 shell 程序。您需要将 sql 脚本硬编码到其中并将其构建为 exe 文件。因此，然后向客户提供运行命令。
或者在 sql server 中使用数据层的另一种方法。MSDN：https ://learn.microsoft.com/en-us/sql/relational-databases/data-tier-applications/data-tier-applications