这就像，“把首饰盒放在屋外，这样强盗就不会费心进去看电视了？”

是的，就是这样。

相对而言，如果您不关心数据库的价值，那么确保将其留在外面是有意义的 - 如果假设应用程序非常不安全，但无论如何您都需要将其放置起来，并且不想保护它，那么这是一种将这个可怕的不安全系统与所有其他内部系统隔离的方法是有意义的。

另一方面，真的没有理由期望拥有这样一个不安全的应用程序，它允许完全接管数据库服务器。此外，没有真正的理由使用“暴露”来替代“隔离”——也有简单的解决方案可以做到这一点。

归根结底，这听起来像是两种可能的情况之一：

1. 这些所谓的“专家”真是一头雾水。
2. 这里还需要权衡其他业务需求。

我认为你的比喻非常有效。如果他们然后告诉您“实际上，那些珠宝是假的，哦，顺便说一句，电视真的是带有金边的 60 英寸 5K 定制工作”，那么这可能是一个明智的权衡（不过最好还是做对).
否则，很可能没有办法解释它，因为他们是在缺乏知识的情况下工作的。

SANS 的“为数据库确保网络安全”（http://www.sans.org/reading-room/whitepapers/application/making-network-safe-databases-24）在某些部分读起来有点过时，但提供了一个在您所追求的方向上提供体面的“傻瓜”级别的指导。

您还可以通过美国 NIST 的资源中心 ( http://csrc.nist.gov/ ) 使自己筋疲力尽。我认为 ISO 的 ISO/IEC 27033-2:2012 也会成为话题，但手头没有副本可以确定。

您正在尝试将最敏感的服务器（数据库服务器）与最暴露（因此易受攻击）的服务器分开/隔离。

您提出了一种“深度防御”方法，旨在 a) 在可能的情况下防止攻击，以及 b) 在没有的情况下延迟它们的进展（以及对重要内容的访问）。

理想情况下，所有内容都始终经过加固和修补，服务器仅侦听所需端口上的流量，并且仅来自允许的设备，未经授权的侦听器（通过加密和/或隔离）无法访问所有“飞行中”的流量，并且监控所有内容以防止入侵和诚信。

如果所有这些都 100% 确定，那么很好，你的“反对派”已经尽可能多地解决了上面的 a) 点。很好的开始，但是 b) 点呢？

如果Web 服务器确实受到损害，那么您提出的架构就会处于一个更好的位置。它们潜在的攻击足迹和向量比它需要的要大得多。

将数据库与 Web 服务器分开的理由与他们接受的将 Web 服务器与 LAN 分开的理由没有什么不同。更坦率地说：如果他们确信受感染的 Web 服务器不会对同一安全区域中的其他系统造成危险，那么他们为什么认为根本需要 DMZ？

处于你的境地真是令人沮丧。至少，在你的位置上，我会创建一份风险备忘录，概述你的担忧和建议，并确保他们承认这一点。无论如何，CYA。

如果数据库包含卡的详细信息，则很容易认为您没有满足 PCI DSS 对适当保护的要求。

它还无法通过单点故障的完整性检查，并保护您的核心资产。

如果数据价值数十亿，为什么不多花几千来增加保护层呢？行业良好的做法是有分层的安全区。

您可以将它们指向 PCI、ISF 的良好实践指南和许多其他内容。

如果您建议将数据库服务器从与 Web 服务器位于同一安全区域中移动到与某些内部系统位于同一安全区域中，那么可以合理地得出结论，您正在降低安全性。

如果现状是 Web 服务器和数据库服务器都在 DMZ 中，并且不允许从 DMZ 到内部网络的连接，那么将数据库服务器从 DMZ 移动到内部网络将需要允许从 DMZ 到内部网络的连接。这意味着您正在降低内部网络的安全性，而没有为数据库获得明显更好的保护。

如果您真的相信数据库比内部网络更敏感（这很可能是真的），那么您不希望内部网络受到任何损害来直接访问数据库。

因此，您需要说明的是，您不想将数据库服务器从一个安全区域移动到另一个安全区域，而是要创建一个全新的安全区域。要真正做到这一点，您实际上必须购买额外的防火墙并将其放在 DMZ 和额外安全网络之间。

然后归结为评估购买和维护这个额外防火墙的成本，以对抗它提供的额外安全性。