目前，我的雇主在3台服务器上部署了一个Web应用程序。是否使用Web服务公开.NET DAL添加安全性？
这样做的原因是该理论认为，如果Web服务器被攻破，他们不直接到达数据库，而是到达DAL框。
在我看来，作为DAL框和Web Sever框 - 都运行Windows/IIS - 如果公共框已经被入侵，相同的漏洞可能会在DAL框上工作 - 因此我不认为这是一个真正的安全利益。
我想建议我们删除中间机器并允许Web服务器直接连接到数据库。
这个中间盒真的是一个好处吗？
Web UI和数据库之间的Web服务层的安全优势充其量是最少的。即使使用slugster建议的网络基础设施，攻击者也只能从他/她的机器上访问Web服务。考虑到这种折衷方案很可能也会给攻击者某种形式的远程访问Web服务器本身，您的网络访问限制是完全没有用的。您可能会设法阻止某些形式的连接，但是如果有人有兴趣访问该框，一旦他们得到它，网络上就没有任何东西能够区分攻击者和合法用户。
更糟糕的是，你被一个额外的代码层所困住，你必须维护它来支持这个额外的层，这意味着你将会有更多的错误，并且需要更长的时间来创建新的特征。
对此的一种方法是利用一些在建筑环境中讨论CQRS的人所描述的技术。特别是在this presentation by Udi Dahan中，他建议将数据库放在Web服务器上，并且只将数据存储在其中，以便支持该Web站点。其他数据，业务数据，存储在别处，存储在一个单独的数据库中。您还可以使用NoSQL数据库（如MongoDB或RavenDB）来呈现数据，并完全放弃关系数据库。
这里有很多选择，其中一些甚至会给你的安全级别认为你得到你当前的架构。给这些决定提供一些批判性思维总是一个好主意，我发现你提出这些问题是令人鼓舞的。
祝你好运。
这几乎是安全的混淆，但中间框提供了额外的安全级别，如果它也由相应的防火墙进行备份。如果数据库被保存在安全的私人防火墙区域，则可以将Web服务机器放置在公共网站可访问的中间层DMZ箱上。尽管利用这个漏洞可以在所有3个盒子上运行，但攻击者仍然必须妥协2级防火墙才能部署漏洞利用。
如果这种性质没有防火墙分离（尽管通过描述听起来好像存在），那么你是正确的，这个漏洞可以重复部署。这听起来像你的公司在网站和Web服务DAL之间有一个防火墙，所以只要连接受到限制和监控，漏洞几乎就变成了非事件。
使Web应用程序通过Web服务联系DAL层可以为数据的安全性添加很多数据。它可能仍然有可能危害网络应用程序，但是您刚刚让剥削者无法进入数据库。
如果您有它设置了这种方式：
web app --> | DAL layer | database
external | network | internal
DMZ
你可以设置你的网络的路由，这样就不可能从外部直接去它位于DMZ中的DAL层，或者甚至可能在网络的内部部分。如果您通过特定端口使用二进制编码WCF，则可以将防火墙规则设置为仅允许Web服务器通过该特定端口连接到包含DAL层的计算机。这意味着如果您的Web应用程序受到攻击，攻击者将获得的最多WCF端点的详细信息，除非他们的攻击从Web服务器启动，否则它们将无法到达。
如果您仅通过使用DAL层中的存储过程等来进一步混淆事件，那么攻击者如果到达DAL就可以执行的操作与Web应用程序使用的数据库功能相同。控制DAL层意味着他可以绕过Web服务器上的任何验证，但理想情况下验证也应该存在于DAL层或数据库存储过程中（这是构建WCF服务的安全方法，您不要总是知道你的Web服务将远离公众视野，也许有一天需求会改变，Web服务将以一种任何人都可以称之为的方式暴露出来）。
假设公共Web服务器被防火墙限制为只有80端口，并且dal盒再次被隔离到只有80端口 - 你是否仍然看到了好处？非常感谢您的答复。 – Jonno 2010-06-12 23:52:34
@Jonno - 只要防火墙在那里，就有绝对的好处。在我工作的地方我们有类似的设置，并且防火墙由运行监视程序的安全小组维护，以检查3个防火墙层之间的所有连接。必须独立利用防火墙的每一层，每次利用攻击都会留下更多足迹。 – 2010-06-13 00:00:56
感谢您的回复 – Jonno 2010-06-13 00:08:36