我们目前的 Web 服务器位于 DMZ 中。Web 服务器无法看到内部网络中的任何内容，但内部网络可以看到 Web 服务器。在 DMZ 和内部网络之间的防火墙上打一个洞，只让内部网中的一台 Web 服务器访问，这样安全吗？我们正在开发一款可以与我们的多个后台应用程序（它们都在一台服务器上）交互的产品，如果我们可以直接与保存这些数据的 IBM i 服务器通信（通过 Web 服务），那么这个项目就会容易得多。
据我所知（我不知道品牌），我们为 DMZ 设置了一个防火墙，其外部 IP 与我们的主 IP 不同，并且还有另一个防火墙。另一个防火墙位于 Web 服务器和内联网之间。
因此类似于：
Web Server <==== Firewall ===== Intranet
| |
| |
Firewall Firewall
| |
| |
Internet IP1 Internet IP2
答案1
当需要实现预期结果时，为 DMZ 中的主机创建访问机制以访问受保护网络中的主机并没有什么错。这样做可能不是最好的选择，但有时这是完成工作的唯一方法。
需要考虑的关键事项是：
尽可能将访问限制在最具体的防火墙规则中。如果可能，请命名规则中涉及的特定主机以及将使用的特定协议（TCP 和/或 UDP 端口）。基本上，只打开尽可能小的洞。
确保记录从 DMZ 主机到受保护网络上的主机的访问，如果可能的话，以自动方式分析这些日志以查找异常。当发生异常情况时，您需要知道。
认识到您正在将内部主机暴露给互联网，即使是以间接方式。随时关注您正在暴露的软件和主机操作系统软件本身的补丁和更新。
如果您的应用程序架构可行，请考虑在 DMZ 主机和内部主机之间进行相互身份验证。如果知道发送到内部主机的请求实际上来自 DMZ 主机，那就太好了。您是否可以做到这一点将高度依赖于您的应用程序架构。另外，请记住，即使正在进行身份验证，“拥有”DMZ 主机的人也将能够向内部主机发出请求（因为他们实际上是 DMZ 主机）。
如果担心 DoS 攻击，请考虑使用速率限制以防止 DMZ 主机耗尽内部主机的资源。
您可能需要考虑使用第 7 层“防火墙”方法，其中来自 DMZ 主机的请求首先传递到专用内部主机，该主机可以“清理”请求，对其进行健全性检查，然后将其传递到“真正的”后端主机。由于您正在谈论与 IBM iSeries 上的后台应用程序交互，我猜您在 iSeries 本身上对传入请求执行健全性检查的能力有限。
如果您以有条不紊的方式处理此问题并保持一些常识，那么您没有理由不能按照您所描述的方式做事，同时将风险降至最低。
坦率地说，如果你拥有一个无法不受限制地访问受保护网络的 DMZ，那么你就会远远超过我见过的许多网络。对于某些人来说，DMZ 似乎只是意味着“防火墙上的另一个接口，可能具有一些不同的 RFC 1918 地址，并且基本上可以不受限制地访问互联网和受保护的网络”。尝试在实现业务目标的同时尽可能保持 DMZ 锁定，这样您就能做得很好。
答案2
显然存在一些危险，但您可以做到。基本上，您打开了一个针孔，有人可以通过它进入，因此请将其缩小。将其限制为仅两端的服务器，并且仅允许所选端口上的数据。使用端口地址转换来使用奇怪的端口并不是一个坏主意。但是，通过隐蔽性实现的安全性根本不是安全性。确保另一端的服务器有某种方式来检查通过该连接的信息是否确实如其所见...或者至少有某种上下文感知防火墙。此外，某些防火墙是为此类事情而设计的...我知道微软 ISA 对 OWA 和 Exchange 服务器也做了同样的事情。