我以前从未部署过反向代理，我想知道从安全角度来看这是否是强制性的，以确保只有经过身份验证的请求才能通过 DMZ 到达我的 Web 应用程序服务器？
我的 Web 应用服务器运行 Linux Tomcat 堆栈，具有所有必需的安全和防火墙基础架构，并且可以验证其自己的请求。我们只是不想将其托管在 DMZ 中，因为它并不总是运行最新的操作系统或 Tomcat 实例。
谷歌搜索“反向代理最佳实践”或“反向代理安全最佳实践”，并没有出现任何强制在代理上启用身份验证的建议。
关于这一点的指导方针是什么？该领域通常的做法是什么？我将不胜感激所有答案，尤其是那些在银行等安全意识强的环境中实际部署了反向代理的人的答案……
提前致谢。
答案1
我认为这个话题没有通用的指导方针。我在不同区域设置了多个反向代理，有时使用身份验证，有时不使用，这在很大程度上取决于实际使用情况。
从你的问题来看
我的 Web 应用程序服务器运行 Linux tomcat 堆栈，具有所有强制性的安全和防火墙基础设施，并可以验证其自己的请求。
我认为，当您的服务器已经进行身份验证时，代理中的身份验证就没有什么意义了。当您想在客户端和不安全的服务器之间建立安全连接时，在反向代理中包含身份验证是有意义的。当您的服务器已经安全时，我认为没有理由再添加一层安全保护。
我之前从未部署过反向代理，我想知道从安全角度来看这是否是强制性的
这绝对不是强制性的。当然，保护原本完全开放的资源是一种很好的做法。因此，如果您的服务器已经“安全”并正在验证请求，我不会添加另一个身份验证实例。
答案2
我曾在一家银行业边缘公司担任基础设施工程师多年，负责在很多人之间转移大笔资金。
我们的系统设计从来不需要代理的身份验证，尽管这些代理无法从外部访问（即在 NAT 后面），尽管应用程序中存在用户身份验证。
这种设置从来都不是问题，而且除了内部审查之外，还有许多外部审计师和外部专家的审计——没有人提出这是一个潜在问题。
也许相关的问题可以帮助您理清思路，因为答案可能会根据部署而有所不同，并且可能会为您的决定提供参考 -
用户绕过反向代理会有什么后果？为什么代理是防范威胁的最佳场所？
如何访问安全代理背后的系统？是否有更合适的位置放置终端节点？除了对代理进行身份验证之外，还有其他方法可以保护代理吗？
答案3
未经身份验证的反向代理的后果是，到达代理的所有请求都会透明地通过网络传递到上游服务器。虽然这可能会导致身份验证失败，但它可以用作对服务器的 DoS 攻击。
DDOS——对上游服务器的攻击
根据您的实现，（在我们的例子中是这样的）代理可以更高效，或者减轻上游服务器的负载，使无效请求失败，从而使上游服务器对其他客户端更具可用性。如果反向代理不是请求到相关服务器的唯一入口点，或者代理和上游服务器之间存在效率差异，则尤其如此。（例如，nginx 与 lua 对比 tomcat）
DOS - 代理攻击
当上游完成身份验证时，代理必须做更多工作（至少 2-3 个系统调用）来读取和写入数据，以便向上游发送和接收所有请求。希望您在代理上进行的身份验证更轻松。如果是这样，向上游发送所有这些虚假数据，即使不会导致上游失败，也会导致代理负载过大，导致代理上出现 DOS 攻击，并会影响使用同一代理公开的所有其他服务。
所有这些向上游传输的流量也可能对代理 -> 上游链路造成压力，尤其是这种非 LAN 流量，具体取决于攻击的规模
应对漏洞
与运行在数十台虚拟机或机箱上的上游解决方案相比，代理设置需要管理的机箱数量要少得多。如果解决方案的核心基础架构存在漏洞，则没有身份验证的代理只会将整个组织暴露在零日漏洞之下，因为这类解决方案无法在一天内修补，更不用说说服公司发布补丁了。但是，代理完全在 IT 控制之下，可以立即修补以防止任何进一步的漏洞。如果保持修补并在边缘使用身份验证，代理实际上在安全性方面是一个巨大的进步。
开放代理的风险
代理的一个典型问题是，有时会出现错误配置，从而允许代理暴露非预期的上游服务器或位置。如果没有身份验证，此代理就会开始充当开放的反向代理，这对企业局域网甚至整个互联网都是一个真正的威胁，因为坏人会利用它隐藏他们的实际位置，以攻击其他目标。开放代理（wrt 重定向）被认为是普遍存在的坏行为。
通过确保您的反向代理具有身份验证，创建开放代理的风险就会变得更小。