我有一个不受限制的 DMZ，目前在里面设置了一个非关键/非敏感的 Web 服务器和数据库服务器。数据库服务器从两个关键系统获取接口，但不存储任何关键信息。我认为数据库服务器至少应该位于第二个防火墙之后。DMZ 应如下所示：
Internet--Firewall--dmz--webserver--firewall--database server--LAN--Interfaces
这是正确的，还是我做的太多，想太多了它需要的保护？此外，与 Web 服务器、数据库服务器和数据库服务器接口的连接应该是 SSL，还是只是数据库服务器与其接口之间的 SSL？我一直认为，更多的保护更好，但我收到了反对意见，我只是想要一个中立的意见。
非关键数据库服务器不一定需要位于第二个防火墙之后，但建议它至少驻留在单独的 DMZ 或同一 DMZ 中的单独 VLAN（具有 ACL 的位置）中。
如果我正确理解您的解释，听起来 DMZ 中的非关键数据库服务器通过 ODBC 连接到 LAN 上的关键数据库服务器？
允许哪一方通过防火墙发起通信？
如果允许非关键数据库服务器发起与局域网中关键数据库服务器的通信（以拉取数据），这是非常糟糕的。
如果 LAN 上的关键数据库服务器正在启动与非关键数据库服务器的通信（以推送数据），则这是更优选的。
在不知道细节的情况下，我质疑为什么这个非关键数据库服务器需要与关键数据库服务器接口，如果它不存储任何敏感数据？
要记住的事情：
如果这个非敏感的 Web 应用程序容易受到 SQL 注入的攻击，那么非关键数据库就会受到威胁。
如果 Web 服务器受到 XYZ 漏洞的攻击，则可以将其用作非关键数据库服务器的攻击点。
k1BLITZ 回答解决了一个关键点——即 DMZ 只需要获得入站流量。这将确保，如果有人接管 DMZ 中的服务器，他将无法进一步（到 LAN）。
为了解决您的其他问题：
讨厌批评，但我认为需要指出这一点。首先，问题的解决方案实际上是以应用程序为中心，而不是以网络为中心的问题。您的修复方法基于旧的端口和进程保护方法。它忽略了其他攻击面的现实。
首先，根据您拥有的防火墙类型，它们的 dpi（深度数据包检测）功能可能有限。大多数漏洞发生在应用程序层，这是主要关注领域将在应用程序层解决。您在 Internet 上的主要表面区域将是 Web 服务器。DPI 将帮助解决的一件事是限制可以对服务器执行的语句类型，除非从 Web 服务器到 DB 的连接是加密的。
即使资源不重要或包含敏感数据，如果数据库受到影响，也会产生一定程度的影响。
基于图表可能更安全的解决方案。这是一个快速的 foo 棒图。
HTTP REQ-> endpoint_filter-> SQL-Statment-code->statement-filter>SQL_Connection_timer->foo
HTTP_RESP<-DPI<-返回函数<-foo -Length -filter N
我看到许多公司因为以网络为中心的思维而被淘汰。