我正在尝试找出处理外部请求的最佳方法。我正在开发一个系统，其中应用程序当前位于外部（DMZ），而数据库位于内部。数据库访问所需的特定端口已从 DMZ 计算机打开到数据库计算机。
经过与团队讨论，我们一致认为 DMZ 不应直接连接到数据库。经过进一步讨论，我们已将以下两种方法列为可能的解决方案。
对我来说，就安全性而言，两者似乎是相同的，因为我们使用相同的通信协议和相同数量的层。
我的理解正确吗？如果正确，B更合理的选择是什么？A这意味着我们有一个自定义数据访问服务，可以处理来自的请求APP并读取/写入数据。
最后，如果我们确实采用B，是否建议我们仍然使用Data Access Service但它是内部的（即APP -> Data Access Service -> DB）
无论应用程序位于反向代理后面还是直接位于 DMZ 中，它都可能存在一些漏洞。额外的数据访问服务包装数据库通信并将其限制为某些结构化 API 调用，而不是允许原始数据库查询。因此，它可以保护数据库免受应用程序中漏洞的影响。
我不会说永远不要与不同防火墙区域中的 DBMS 建立 IP 连接，但是正确地做到这一点很困难。
DBMS 通常不会通过 IP 网络暴露给公共流量，因为它们尚未为此目的进行强化。它们的在线协议应该定义明确，使用加密、强身份验证和访问控制。但在实践中，设置一些不应该出现在互联网上的弱协议实在是太容易了。
例如，与 ssh 相比，ssh 是一种为不安全网络设计的互联网标准，实际上在互联网上数十亿台主机中使用。
或者 http。http 动词也能很好地映射到通用事物，因此 http API 无处不在，包括您提议的应用程序架构中。方便的是，众所周知的 http 服务器在多年面向公众提供网页服务后已经得到了强化。作为代理，它们非常适合用作生产质量的前端层。
虽然您的任何一种想法都会将 DBMS 流量转移到不同的防火墙区域，但前端面向用户的软件的成熟度也很重要。解析任意输入（例如从网络流量中解析应用程序请求）非常困难。无论哪种情况，都请考虑在应用程序前面使用代理。一个好的通用代理是一种久经沙场的传输，是安全和负载平衡方面的已知量。
更好的网络设计可能会进行更多的分段和更少的信任。将中间应用程序层与 DBMS 进一步隔离。例如，应用程序没有理由获得 DB 的 shell，因此使用防火墙规则拒绝 ssh 和其他未使用的协议。