Das*_*cal 6 architecture security encryption config
只是一个一般的架构问题.
我知道对于网站,可以使用IIS内置的功能来加密连接字符串部分.但是,我不确定的是...如果我这样做然后将web.config复制到另一个项目,新项目是否仍然能够解密配置文件中的连接字符串部分？
这成为问题的是生产数据库访问.我们不希望任何人能够将配置文件从生产复制到他们的项目中,并且可以对生产数据库进行全权访问.
目前我公司的方式是将加密的连接字符串存储在服务器的注册表中,然后使用本地工具读取注册表并动态解密该值.这可以防止有人只是查看注册表或Web配置来查看连接字符串.
此外,对于胖客户端(WinForms,WPF等)应用程序,这可能会有点问题,因为再次,我不确定IIS加密技巧是否会起作用,因为应用程序不会在IIS上运行.我们目前有一个kludgy解决方案,它涉及相同的本土应用程序,但从二进制文件读取加密的字符串,并在运行中解密.
它似乎非常拼凑,我们正在寻找一种更好的方法(即行业标准,当前技术等)
所以,更普遍的问题是......
您使用什么方法来保护连接字符串？特别是涉及到访问它的多种应用程序类型,加密等.
快速谷歌搜索将向您显示其他人尝试加密部分或全部应用程序配置文件(即Google"ecnrypting应用程序配置文件").
但通常情况下,我发现更好的答案是正确保护您关注的资源(通常是数据库).Windows身份验证始终是SQL身份验证的首选,因此密码不需要存储在配置文件中,尽管这可能并不总是一个选项.如果您想阻止对资源的访问(特别是如果它通常通过任何类型的Web层访问,如Web服务或网站本身),那么将资源托管在不同的服务器上(无论如何都是首选的),而不是允许从内部网络外部访问它.如果攻击者可以访问您的内部网络,那么通常比您要保护的资源更重要.
如果您担心恶意人员执行即使您的应用程序无法执行的操作(例如删除数据库),那么请确保应用程序正在使用的凭据也不具有该类型的权限.这显然不能防止攻击,但它可以减少从中造成的伤害.
恕我直言,保护存储在用户机器上的配置文件中的信息通常不值得花时间.在一天结束时,机器本身将需要能够解密信息,并且如果机器具有这样做的手段,那么用户也是如此.你可以让用户很难做到,但它通常仍然可行.
这不是你问题的直接答案,但我希望它能让你思考一条可能导致可接受解决方案的不同路径.