在这种情况下要考虑的主要方面是深度防御和设计安全。正如您正确指出的那样，在防火墙和端口转发层之后添加层确实会增加复杂性，但不能单独防御攻击。

成功的攻击是时间和精力的函数，因此任何事情都可能受到损害。考虑到这一点，您需要进行威胁评估，并考虑每个网络和每个系统的危害和可能性以及由此产生的附带损害。

使用您的示例，您可以使用 DMZ 来控制攻击者的横向移动，以防发生违规行为。至关重要的是，横向移动将使用任何网络和任何协议发生，这些协议恰好可以通过利用先前的攻击来利用或破坏。因此，最小化 DMZ 中服务器的连接范围是有意义的——这将是您的 Web 服务器。您在外围防火墙上的端口转发确保从 Internet 访问 Web 服务器的唯一方法是通过 Web 服务器端口，因此您再次限制了来自 Internet 的攻击面。此外，您需要确保服务器配置安全，并且除了绝对必须公开的服务之外，没有其他服务被公开，如果可以的话，

如果 Web 服务器需要连接到数据库（它经常这样做），那么您需要它来连接该端口是正确的。这不是安全漏洞，而是操作要求。您可以将服务器放在与 Web 服务器相同的 DMZ 上，也可以放在不同的 DMZ 上。后者更加努力，但可以说是更好的安全性。再次考虑数据库服务器，您将希望尽可能加强其配置，包括使用基于主机的防火墙。还应该使用具有强密码的多个帐户（而不是使用具有弱密码的 dba 帐户，因为“它是内部的”）等使用 Web 服务器安全地配置数据库。

有了这一切，你最终得到的远不是一个无法攻破的架构，而是你尽可能难以攻击、妥协和横向移动的架构。

要破坏数据库服务器（前提是攻击者没有通过 Web 服务器上的数据库连接完成此操作），攻击者需要首先以某种方式破坏 Web 服务器，然后继续攻击数据库。数据库服务器需要足够弱（或易受攻击）才能受到损害。

让我们退后一步，重新审视 DMZ 的概念。

在谈到大多数事情，尤其是技术性的事情时，我们总是使用某种形式的类比。只要我们保持在适合类比的水平和理解上，这些类比就可以方便地快速参考。如果我们探索得足够深，每一个类比都会被打破。

我们经常说“非军事区”或“在非军事区”，好像它是一个事物或一个地方，但它不是。

将设备（通常是服务器或路由器）连接到 Internet 时，最初的问题是您要打开/允许哪些端口。

相关的问题是，您想对在先前指定的端口以外的端口上进行通信的尝试做什么？如果您的回答是“Nothing 或 Block”，那么您就完成了，没有 DMZ。

当您想为其他未指定的端口分配服务器/处理程序时，DMZ 的概念就会发挥作用。DMZ 是一条规则，将这些其他端口发送给我的处理程序。同样，如果您不需要或不希望处理其他端口，则不需要 DMZ规则。

当面向 Internet 的设备是路由器/防火墙（又一个类比）时，类比变得复杂，但还没有被打破。这里最初的端口接受是（应该是）不接受任何端口。为了变得有用，其他端口规则开始发挥作用。指定 443 等其他端口可以​​设置为转发到您的 443 网络服务器。这不是真正的 DMZ，因为它是一个指定端口，但许多 SoHo 路由器将此端口转发控制置于 DMZ 的子类别下。

DMZ 是更多未指定的端口。你可以有一条规则，“将所有其他端口发送到我的特殊处理程序箱”。

所以你的一些细节：

“反向代理是否应该是 DMZ 中的唯一服务器”

反向代理（通常称为反向服务器）根本不是服务器，而是客户端。它没有从路由器转发的静态开放端口，只有动态出站启动端口。完全没有DMZ！

“只要反向代理不向它重定向任何东西，将没有端口转发到的数据库放置在 DMZ 中真的不安全吗？”

这是不合逻辑的。你没有 DMZ，即使你有，DMZ 也是一个规则。由于没有到数据库的转发规则，它不在 DMZ 中。

在这里，DMZ 类比开始失效。将两个防火墙之间的网络部分称为 DMZ 已成为一种常见用法。它可能是也可能不是防火墙规则的功能。

如果您所拥有的只是一个连接到您的反向代理的 Web 服务器的数据库，那么您只需要适当的端口控制。完全没有DMZ。

实际上，您可能希望在您的数据库和 Web 服务器之间设置另一个防火墙，以尝试防止可能的 Web 服务器受损，但这与 DMZ 的概念无关。