我们希望放弃现有的解决方案，使用更简单（更便宜）的 SFTP 服务器来允许与客户端进行文件交换。我们的网络由 Trusted 网络和 DMZ 网络组成。当前产品通过在两端托管服务器并负责桥接本身来满足这一要求。我们希望切换到 WinSSHD，但不确定服务器的位置、DMZ 还是 Trusted。我们从事金融行业，正在寻找最佳实践的指导，或者可能是满足我们要求的良好替代方案。
我们确实应该将其放在 DMZ 中，但随后我们必须弄清楚如何将文件从那里移动到受信任区域。
答案1
如果它是一台可公开访问的服务器，则应将其放置在 DMZ 中 - 这就是分区的意义所在。设置具有两个接口的服务器 - 一个在 DMZ 中，一个在受信任网络中 - 只会规避单独 DMZ 的概念，使其完全多余。
对于位于 DMZ 中的服务器，一般来说你应该
- 确定存储在其中的数据是否可以安全地在“受信任”网络内复制和使用
- 如果是，则允许服务器和受信任网络之间的数据传输机制
您只需使用与客户端相同的协议即可轻松实现 2. - 通过 SFTP 连接并提取数据。这样，您就无需为额外协议套件进行风险评估。
编辑：我将尝试采用类似 wiki 的风格，并将您的反对意见纳入此答案并对其进行评论：
数据现在位于 DMZ 中，我必须在内部寻找答案，看看是否允许。当前解决方案不会将数据物理存储在 DMZ 中，它只有一个 DMZ 接口。
当然，由设计安全策略的人来平衡“存储”在 DMZ 中的数据被盗风险与在受信任网络中虚拟托管可公开访问的服务之间的风险。在大多数情况下，您会选择前者，同时通过将数据仅保留在 DMZ 中一段有限的时间，将数据被盗风险降至最低。
另一个选择是实施SFTP 的代理解决方案在您的 DMZ 中并将连接转发到您的“受信任”的服务器 - 但这会有一个不同的攻击面，因此它再次最终平衡风险。
这比简单地在受信任的环境中托管 SFTP 并允许直接连接更安全吗？
代理通常设置为具有“良好行为”的协议交换。这可以缓解基于利用服务器端协议实现中的弱点（例如缓冲区溢出）的一系列攻击媒介。某些代理设置可能允许您指定用户可以或不能执行的操作的限制 - 此功能用于通过仅允许必要的操作来减少攻击面。
但代理只是一段容易出错的代码，就像其他代码一样 - 它有自己的攻击媒介。对于具有两个服务器和轮询的“水门”设置，威胁建模和风险评估更容易评估。
我需要使这个过程自动化，所以我必须使用某种文件监视服务来监视 DMZ 中的传入文件，然后转发到 Trusted 中的另一个 SFTP 服务器。
是的，这是一个合理的做法。
现在我真的必须在围栏的每一侧管理 2 个 SFTP 服务器。
正确，但它们每一个本身都可以是一个安全边界——如果你非常关心存储在那里的数据的安全性，这可能是一个要求。
答案2
这里有几点想法与 syneticon-dj 所说的一致：
编辑：添加了 Nate 的观点：Linux 学习曲线/Windows 权衡。
如果您熟悉 Linux 和/或愿意为该应用程序投入一些时间来学习它，我不建议您使用 Windows，因为 Linux 或 FreeBSD 等完全适合 *NIX 操作系统。我根本没有批评 WinSSHD（我最近才知道它，并认为它是一款很棒的产品，可用于通过 SSH 隧道传输 RDP 等），但 *NIX 和 OpenSSH 确实可以工作很好，为什么要费心使用 Windows 和支付许可费用呢？*NIX 可以说开箱即用，更加安全，尤其是使用 Debian 最小安装之类的东西，它在易用性（apt 包管理）和占用空间小之间取得了很好的平衡。
将服务器保留在 DMZ 中。你不需要两个 SFTP 服务器，你需要一个 SFTP 服务器和一个 SFTP客户在您信任的网络上，可以根据业务需求从 DMZ SFTP 服务器中拉下您的文件。
这可能只是一个 rsync cronjob，它定期使用参数执行同步“拉取”操作，比如每 15 分钟一次，
--delete-after这样一旦数据被下载到您信任的主机，DMZ 服务器中就不会留下任何数据。根据您的喜好，它可以尽可能地强大，并且是一种非常常见的模式（适用于 99% 的 POP3 实现）。您可以添加一些健全性检查和一些业务逻辑（在删除数据之前验证数据），并且可以使用事件驱动模式进行优化（仅在有新数据时提取），但 rsync 本身非常高效，因此您可能可以使用这种简单的暴力方法，特别是如果这是一个手动过程。好处是，除了一些传出规则允许您信任的 SFTP 客户端主机连接到您的 DMZ 网络之外，您的 DMZ SFTP 服务器（如果受到威胁）就无法直接访问您信任的网络中的任何内容。