【问题标题】:for securing a database that is meant to be accessed by several clients, is using a web service as a proxy an overkill?为了保护打算由多个客户端访问的数据库,使用 Web 服务作为代理是否过大?
【发布时间】:2012-08-15 20:02:22
【问题描述】:

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

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

为了创建这个应用程序,我们得到了一个建议,即部署一个 Web 服务作为客户端和数据库之间的代理,以保护数据库。

但我们不会传输任何敏感数据(例如信用卡号或...),我们只担心未经授权的人无法修改数据库。

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

【问题讨论】:

    标签: c# database web-services security


    【解决方案1】:

    这可能是矫枉过正,但也可能不是。决定采用面向服务的架构可能基于几个因素,其中包括:

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

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

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

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

    【讨论】:

      【解决方案2】:

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

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2018-05-16
        • 2014-12-14
        • 1970-01-01
        • 2014-08-17
        相关资源
        最近更新 更多