我们正在尝试决定应将不同的服务器放在哪里。我们应该将它们放在 DMZ 中吗？还是放在我们受信任的网络区域中？等等... 关于这个主题的文章很多，但对于是否允许从 DMZ 访问内部网络上的数据库服务器，似乎存在不同意见。我希望您能对我们的想法发表意见。
基本上，我们在为客户提供服务时涉及以下服务器和服务：
“应用服务 (WCF)” 基本上是我们进入数据库的入口点，它保存所有业务逻辑，并在将其提交到数据库之前验证一切正常。这里还有一个只读服务，针对查询数据库进行了优化。
引入 DMZ 后，我们应该把服务器放在哪里？Web 服务器和外部服务显然会进入受防火墙保护的 DMZ，仅允许必要的端口。但是应用程序服务和数据库服务器呢？我们考虑了以下场景：
- 应用服务和数据库服务器在内部网络中，受防火墙保护，只允许外部Web服务器和服务直接连接到应用服务，而不是数据库。
- 应用服务在DMZ中，数据库服务器在内部网络受防火墙保护，允许应用程序连接到数据库。内部应用程序将连接到DMZ中的应用服务。
- DMZ 中的一切。
- 通过在 DMZ 中放置只读数据库和消息队列，将 DMZ 与内部网络完全隔离。从内部网络到 DMZ 的单向访问，允许内部数据库将事务复制到 DMZ 数据库以保持最新状态。命令不是写入 DMZ 数据库，而是写入消息队列，并从内部服务中获取，并由应用程序服务处理（我们可以忍受延迟）。此方案还涉及拆分应用程序服务，因此它仅由只读查询服务和将命令放在 DMZ 队列中的服务组成。原始应用程序服务仍将在内部网络上处于活动状态。这里有一些重复的代码，但如果这是最佳方案，我们可以忍受。
据我所知（我不是网络专家），方案 1 或 4 似乎是最合适的解决方案。在解决方案 1 中，DMZ 没有直接连接到我们的数据库，但有一个从 DMZ 到内部的端口是开放的。在解决方案 4 中，DMZ 没有向内部开放任何内容，但我们在 DMZ 中公开了数据库的只读副本。该数据库包含大量敏感的客户信息，因此这可能不是理想的选择。
您觉得如何？任何想法和意见都将不胜感激。
答案1
我认为解决这个问题的最简单方法是从另一个角度入手：问“如果发生入侵，会发生什么？”。如果外部 Web 服务器被入侵，那么攻击者可以从那里跳转到哪里？让我们看看这些选项：
- （您没有提到这一点，但为了完整起见，我把它放在这里。）如果防火墙被攻破，内部网络中的所有内容都会被攻破：您就完蛋了。如果 Web 服务器被攻破，攻击者就有可能访问内部网络上的所有内容（而不仅仅是数据库服务器）。
- 外部 Web 服务器位于 DMZ 中，应用服务位于 DMZ 中，数据库服务器位于内部网络中：对攻击者而言，这是一个额外的障碍：只有 Web 服务器和应用服务均被攻陷，攻击才有可能跳转到数据库。成功的攻击意味着攻击者有可能访问内部网络上的所有内容。
- DMZ 中的所有内容：成功的攻击无法访问内部网络。
- 通过在 DMZ 中放置只读数据库和消息队列，将 DMZ 与内部网络完全隔离...：最大限度地减少了从 DMZ 跳转到内部的可能性，但并未完全消除这种可能性。需要额外的复杂配置和工作来确保一切“恰到好处”。
我个人倾向于采用下一级保护：所有东西都放在 DMZ 中，数据库服务器及其所有重要内容都受到第二级保护，但仍在 DMZ 中。当然，这会增加复杂性，可能不值得付出努力。实际上，这取决于数据库服务器中的内容到底有多重要，以及您的公司有多大。它可能只需锁定数据库服务器以便只有 Web 服务器可以访问它就足够了，但这是除了您之外没有人可以做出的价值判断。
答案2
这是一个真正的大问题，一方面我们担心黑客会访问公司数据，另一方面又想在 DMZ 中保留一个只读数据库。但是我们要把什么放在只读数据库中呢？如果它是敏感的 PII 数据，您的 IT 安全措施根本就不允许它。我想说我们在应用程序上有一个代理客户端，并且通过 RMI 或 HTTPS 连接到安全的内部网络。通过代理执行调用，这有助于维护一个保险库数据库，而不必担心将数据暴露给外部无情的世界。