客户端有一个限制性的networking。 他们不需要传入连接，他们没有VPN。 我们正在安装外部pipe理员需要访问的pipe理工具。 一种解决scheme是pipe理员访问pipe理工具的基于云的版本，而来自他们networking的cron作业偶尔抓取数据并更新内部pipe理工具。 这是一个巨大的麻烦。 现在我们必须处理数据争用问题，延迟等。我宁愿不这样做。
这里是我的问题：如果我提出从pipe理工具服务器到外部pipe理员用户可以login的基于云的SOCKS代理的反向隧道，IT团队可能认为这是一个安全的替代scheme吗？
这不是一个疯狂的想法，它肯定比传入的连接更安全，所以它不是一个可以接受的不好的build议/妥协。 也就是说，反向代理并不能防止写入不好的应用程序，像SQL注入这样的漏洞将通过反向代理传递，除非你也在代理的末尾实现对请求的过滤和检查，所以仍然存在某种程度的风险。
我工作的公司之一有一个类似的问题，当为内部安装（不是每个人都喜欢云），为远程用户提供移动访问专有软件，解决scheme是使用Azure的混合连接 ，它基本上是一个反向代理，但不知何故一个基于微软Azure的解决scheme似乎可以提高客户的接受度，并受到好评。