将数据访问放在web服务中比放在当前项目中的类中更安全吗？

Question

我们有几个项目，我们将所有数据访问放在一个单独的web服务项目中，父项目将调用与数据相关的所有web服务。web服务将只接受来自web项目服务器的连接。我的假设是，通过这种方式，web服务不太容易受到入侵。我不太确定这是不是正确的。

这是否比仅仅将数据访问放在父项目中的类或dll中更安全？

备注

我上面的开发人员做出了这个决定。

Answer 1

我不认为这是保护数据库安全的有效方法。在所有现有的保护数据层的方法中，我不认为将调用从类库转移到web服务是保护您自己的有效方法。

一种更好的方法是确保使用参数化查询或存储过程来防止SQL注入，并将您的登录权限限制为只执行他们需要执行的操作。

然而，在单独的web服务中进行数据访问可能会有其他的论点……例如可重用性或面向服务的体系结构。如果在多个服务器上的不同项目中需要相同的数据访问层，那么通过使用web服务，您将不需要在各地复制相同的类库……这会使您担心哪个项目具有哪个版本的数据访问层。

所以，更安全了？我不这么认为。其他好处？很可能..。

Answer 2

简短的回答:是的。

更长的答案:我的假设是，公开服务的web服务器在它自己的防火墙后面。通过这种方式，如果黑客能够危害您的应用程序服务器，则会迫使黑客穿过另一层，从而使数据库免受入侵。由于应用程序服务器上不存在数据库连接字符串，并且防火墙阻止了从该服务器到数据库的直接连接，因此黑客需要以某种方式穿透该防火墙并获得对托管数据服务的服务器的访问权限。

现在，我还假设web服务不是简单地公开像这样的方法

execute(string sqlCommand)

如果是这样的话，这种解决方案实际上可能比简单地使用没有web服务的数据库更不安全。为了让这个解决方案真正更安全，您需要在web服务服务器上创建特定于操作的方法。

Answer 3

据我所知，DLL不能从Web访问和执行。Web服务可以。如果这是真的，则Web项目(甚至Web服务)引用的类库比直接封装该逻辑的Web服务更安全。

此外，还有关注点分离的整个概念。在我看来，数据访问逻辑属于一个单独的层，与业务逻辑完全分离。在设计良好的体系结构中，Web服务公开表示业务事务的离散方法--不一定是数据事务。业务事务封装一个或多个数据事务，这些数据事务由单独的类表示，这些类封装数据访问逻辑并提供安全性，以确保SQL注入永远不会发生。

当然，其他人可能不同意。我们是开发人员。这是我们的天性，不同意。:)