C# 中应用程序配置文件的“静态”加密

Question

这是我几个月来一直在思考和搜索的问题。

在特定的场景中，我在网络共享上有一个应用程序，它连接到数据库以检索一些信息。 数据库的连接字符串是静态的，包括用于建立与数据库的只读连接的用户名和密码。 显然，连接字符串不能只以纯文本形式存储，对于从网络中不同计算机启动应用程序的所有用户来说，连接字符串必须保持不变。

这是我未能以令人满意的方式破解的坚果：

到目前为止，我发现的所有教程都使用内置的 .net-functions 来保护 app.config 文件的连接字符串部分（如 RSAProtectedConfigurationProvider），这非常适合用户范围的加密，但不能用于所描述的场景，因为 rsa 容器是为特定用户/计算机生成的，因此只有这一个用户/计算机能够从曾经加密的配置文件中读取 - 还是我在这里遗漏了一点？

我最后的尝试是编写一个以某种方式混淆的方法来在应用程序中生成一个静态字符串，用它加密我的连接字符串，并在每次需要建立数据库连接时调用它。 这可以完成工作，但通过简单的反编译程序并不难被破解，提取加密/解密方法将其应用于也提取的连接字符串。

我想知道是否有一些技术可以保护应用程序范围内的连接字符串等敏感数据，因此它只有应用程序本身知道并且所有用户都知道它是静态的，但不能通过简单地反编译程序来提取。

也许我在这里认为完全是在错误的盒子里，但我发现对于这个看起来很常见的问题似乎没有开箱即用的解决方案非常模糊。

Answer 1

你是对的。除非您可以将加密密钥 100% 保密，否则无法 100% 保护您的加密数据。不幸的是，在这种情况下，混淆或“通过隐藏来保护”仍然是您的最佳选择。

作为替代方案，您应该通过为数据层创建 Web 服务来将共享应用程序与数据库分离，并让您的应用程序访问该服务，而不是直接访问您的数据库。保护 Web 服务的最简单方法是为其启用集成 Windows 身份验证，并确保您的客户端应用程序在访问它时使用默认用户的域凭据，使用凭据缓存。 .NET 中的实现很简单。

从可扩展性和性能的角度来看，Web 服务方案也更可取，尤其是当您的客户端应用程序实例要从不同的办公室运行时：非常不建议通过 WAN 链接或 Internet 进行直接数据库调用，因为那样协议非常健谈。与数据库位于同一位置的 Web 服务是一个更好的解决方案，尤其是在使用远程客户端时，因为所有调用都降级为每个调用的单一请求-响应类型的流量。 （或者，在进行身份验证时，可能是两次往返。）

Answer 2

这就是许多体系结构将服务器应用程序作为客户端应用程序之间的中介的原因。这样，加密的配置使用服务器应用程序在其下运行的用户的上下文（例如，对于 Web 应用程序，ASP.NET 应用程序池在其下运行的身份），因此客户端用户无法访问配置，也无法直接访问数据库.

直接连接到数据库的 Intranet 应用程序

您的场景对于 Intranet 桌面应用程序非常常见，并且由于您的客户端应用程序直接访问数据库，因此最好的方法是在数据库级别使用每个用户的权限。这可以使用集成安全连接字符串而不是使用 SQL 用户名/密码来完成。在 SQL Server 中，您可以将 Active Directory 组映射到权限，并且将使用该应用程序的任何人都必须将其 AD 用户添加到 AD 组。一般来说，这对于小型 Intranet 环境来说已经足够了，在这些环境中，用户在一定程度上受到信任并对他们的行为负责。

这可确保未经授权的任何人都无法获取应用程序的副本并使用连接对数据库执行未经授权的查询。如果您真的关心安全性，则应将数据库级别的任何权限视为用户可以利用该权限。

例如，考虑一下：您的应用程序需要 Product 表的删除权限，因为它的代码可以在产品到达某个非活动日期时删除单个产品。但是，任何用户都可以使用该连接来删除表格的全部内容，而不管您的客户端应用程序被编程为做什么（当然，这需要他们的聪明才智来创建一个工具来执行这个，但在谈论安全性时这通常是一个静音点）。

这就是客户端-服务器架构的原因，因为一旦涉及到服务器并且客户端不再直接连接到数据库，那么您可以确信与数据库的交互遵循某些定义的行为。当您的客户端直接连接到数据库时，使用该客户端的任何人都可以通过足够的努力找到使用该连接并滥用权限的方法。