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

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

这是我未能令人满意地破解的坚果：

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

我的最终尝试是编写一种经过某种方式混淆的方法,以在应用程序内部生成静态字符串,用它加密我的连接字符串,并在每次需要建立数据库连接时调用它.
这样就可以了,但是通过简单的反编译程序很难被黑客入侵,提取加密/解密方法将其应用于同样提取的连接字符串.

我想知道是否有某种技术可以保护应用程序范围内的敏感数据(如连接字符串),因此仅由应用程序本身知道,并且对所有用户而言都是静态的,但不能通过简单地反编译程序来提取它.

也许我在想在这里的错误框中填写completley,但是我发现对于这个看起来很普遍的问题似乎没有开箱即用的解决方案是很晦涩的.

解决方法:

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

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

对于Intranet桌面应用程序,您的情况非常普遍,并且由于客户端应用程序直接访问数据库,因此最好的方法是在数据库级别使用每个用户的权限.可以使用Integrated Security连接字符串而不是使用SQL用户名/密码来完成此操作.在SQL Server中,您会将Active Directory组映射到权限,并且将使用该应用程序的任何人都必须将其AD用户添加到AD组中.通常,这对于小型的Intranet环境就足够了,在这种环境中,用户在某种程度上受信任并对他们的行为负责.

这样可确保任何未经授权的人都无法获取该应用程序的副本,并使用该连接对数据库执行未经授权的查询.如果您确实担心安全性,则应该在数据库级别对待任何权限,就好像用户可以利用该权限一样.

例如,请考虑以下情况：您的应用程序需要对Product表的删除权限,因为它具有用于在产品达到某个非活动日期时删除单个产品的代码.但是,任何用户都可以使用该连接来删除表的全部内容,而不管您的客户端应用被编程为做什么(当然,这需要聪明的人来创建工具来执行此操作,但这通常是谈论安全性时的静音点).

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