为了保护其公共 HTTP API(所谓的 REST),我的客户要求我实现一个简单的 HTTP 反向代理,该代理将验证(OAuth 2.0)访问令牌并将 HTTP 请求转发到内部 Web 服务进行处理。
这个想法是我的客户端具有“强大的”网络级安全性:位于代理后面的各种 Web 应用程序将没有安全约束,因为它们无法从外部访问。当多个内部服务相互调用时,他们希望保持调试简单。用于内部调用的纯 http,没有 TLS。
我认为让内部应用程序“完全开放”是一个糟糕的主意,因为任何设法进入网络的攻击者基本上都可以免费访问敏感(明文)客户数据……而历史似乎证明这种情况经常发生. 从操作的角度来看,从代理(OAuth 范围/URL 匹配)强制执行细粒度约束(如 ACL)并在部署新服务时保持配置是最新的将是一件痛苦的事情。
你们看到我遗漏了什么吗?实施应用程序级安全性的任何其他论点?
编辑:一些我没有明确提及/解释的重要细节:
- 我在这里谈论的 Web 应用程序(仅隐藏在安全代理后面)都是 Web 服务。
- 具有用户界面(公共/内部“站点”)的 Web 应用程序位于另一个网络区域,与相关 Web 服务相比,具有一些不错的应用程序级安全性。
我提到的“强大”网络安全都是关于区域的,最终用户(和未经授权的内部人员)理论上无法直接访问 Web 服务(只能通过代理)。我猜操作人员在访问机器时仍然可以提供某种路由,如答案中所述。