这是我一直在考虑和在互联网上搜索几个月的问题。
在特定的szenario中,我在网络共享上有一个应用程序,它连接到数据库以检索某些信息。 数据库的连接字符串是静态的,包括用于建立与数据库的只读连接的用户名和密码。 显然,连接字符串不能只以纯文本形式存储,而是必须保持从网络上不同计算机启动应用程序的所有用户保持不变。
这是我未能以令人满意的方式破解的坚果:
到目前为止我发现的所有教程都使用内置的.net函数来保护app.config文件的连接字符串部分(如RSAProtectedConfigurationProvider),这对于用户范围加密非常有用但不能用于描述场景的rsa容器是为特定用户/计算机生成的,因此只有这一个用户/计算机能够从曾经加密的配置文件中读取 - 或者我在这里错过了一个点?
我最后的尝试是编写一个模糊的方法来在应用程序内部生成静态字符串,用它加密我的连接字符串并在每次需要建立数据库连接时调用它。 通过简单的反编译程序来完成工作,但不是很难被黑客攻击,提取加密/解密方法将其应用到也提取的连接字符串。
我想知道是否有一些技术可以保护应用程序范围内的连接字符串之类的敏感数据,因此只有应用程序本身才能知道,并且所有用户都知道静态,但只能通过反编译程序来提取。
也许我在这里错误的方框内思考,但我发现它似乎没有开箱即用的解决方案来解决这个相当常见的问题。
答案 0 :(得分:2)
你是对的。除非您可以100%保密加密密钥,否则无法100%保护您的加密数据。混淆或通过模糊来保护"不幸的是,它仍然是你在这种情景中的最佳选择。
作为替代方案,您应该通过为数据层创建Web服务来使您的共享应用与数据库分离,并使您的应用访问该服务,而不是直接在数据库之后。保护Web服务的最简单方法是为其启用集成Windows身份验证,并使用凭据缓存确保客户端应用程序在访问时使用默认用户的域凭据。 .NET中的实现很简单。
从可扩展性和性能的角度来看,Web服务方案也是可取的,特别是如果您的客户端应用程序实例要从不同的办公室运行:通过WAN链接或Internet进行直接数据库调用是非常不可取的。协议非常健谈。与数据库位于同一位置的Web服务是一种更好的解决方案,尤其是在使用远程客户端时,因为所有呼叫都会降级为每个呼叫的单个请求 - 响应类型的流量。 (或者,可能是两次往返,当认证正在进行时。)
答案 1 :(得分:1)
这就是许多架构涉及服务器应用程序作为客户端应用程序之间的中介的原因。这样,加密配置使用运行服务器应用程序的用户的上下文(例如,使用ASP.NET应用程序运行的Web应用程序的身份),以便客户端用户无法直接访问配置或数据库
直接连接到数据库的Intranet应用
您的方案对于Intranet桌面应用程序非常常见,并且由于您的客户端应用程序直接访问数据库,因此最佳方法是在数据库级别使用每用户权限。这可以使用集成安全性连接字符串而不是使用SQL用户名/密码来完成。在SQL Server中,您可以将Active Directory组映射到权限,并且将使用该应用程序的任何人都必须将其AD用户添加到AD组。通常,这对于小型Intranet环境来说已经足够了,在这种环境中,用户可以信任并对其行为负责。
这可确保没有未经授权的人可以获取应用程序的副本并使用该连接对数据库执行未经授权的查询。如果您真的关心安全性,则应该在数据库级别处理任何权限,就像用户可以利用该权限一样。
例如,请考虑以下事项:您的应用程序需要对Product表具有删除权限,因为它具有在产品达到某个非活动日期时删除单个产品的代码。但是,任何用户都可以使用该连接删除表格的全部内容,无论您的客户端应用程序被编程为什么(当然,他们需要聪明才能创建一个工具来做这个,但这通常是谈论安全时的一个静音点)。
这就是客户端 - 服务器体系结构的原因,因为一旦您涉及服务器并且客户端不再直接连接到数据库,那么您可以确信与数据库的交互遵循某些已定义的行为。当您的客户端直接连接到数据库时,使用该客户端的任何人都可以付出足够的努力找到使用该连接并滥用权限的方法。