为了保护几个客户端要访问的数据库,使用Web服务作为代理是否过度杀伤?

时间:2012-08-15 20:02:22

标签: c# database web-services security

我们将拥有一个数据库,以及一个将安装在本地网络中的多台计算机上的客户端应用程序,并且他们必须能够访问该数据库。

其中一些必须能够编辑和修改数据库,其中一些只是阅读它们。根据谁必须能够访问哪个表/字段,这两个组中的每一个也被分成几个组。

为了创建此应用程序,我们提出了将Web服务部署为角色作为客户端和数据库之间的代理的建议,以保护数据库。

但是我们没有传输任何敏感数据(例如信用卡号码或......),我们只担心没有未经授权的人能够修改数据库。

不仅仅是在app.config中使用integrated security选项了吗?
我们真的需要隐藏和保护连接字符串吗?

2 个答案:

答案 0 :(得分:1)

对我来说听起来太过分了。如果应用程序仅在内部使用,并且Windows身份验证是一种选项,请务必使用它。构建Web服务只会减慢开发速度并增加不必要的复杂性。读/写用户可以是具有对数据库的读/写访问权限的Windows组的成员,只读用户可以是仅具有对数据库的读访问权的Windows组的成员。然后,如果用户能够直接访问数据库(不使用您的前端),他们将只能根据Windows权限进行读取或读取/写入。

答案 1 :(得分:1)

这可能是矫枉过正,但可能不是。决定转向面向服务的体系结构可以基于几个因素,其中包括:

  • 您希望维护此应用程序多长时间?
  • 您期望有多少客户端部署?
  • 您希望您的数据库经常更改吗?
  • 您的SLA要求是什么?
  • 您是否希望数据库最终用于其他应用程序?
  • 等...

如果您希望能够更改中间层或数据库中的内容,并且您不希望在执行此操作时升级每个客户端,那么它的长短不一,添加服务层可能是要走的路。您还可以为其他客户端开发人员(内部或外部)提供丰富的API,同时在一个集中位置控制业务规则和安全性。

SOA肯定会增加项目的复杂性,但在很多情况下,它可以为您节省很多麻烦。

如需进一步阅读,请查看http://en.wikipedia.org/wiki/Service-oriented_architecturehttp://www.soapatterns.org/或Google。