内部Web应用仅对指定外部厂商开放的方案选型及反向proxy可行性咨询

反向代理方案可行性结论 #

你提出的在内部Web应用前部署反向代理转发请求的方案完全合理可行，是目前企业对外开放内网服务的主流基础方案，能完全避免内网应用直接暴露在公网环境中。

反向代理层推荐加固配置 #

要实现仅对指定厂商开放权限，建议你在反向代理层叠加以下访问控制规则：

• 配置IP白名单：仅允许合作厂商的公网出口IP访问反向代理入口，其余所有公网IP的访问请求直接在网络层拦截丢弃，从根源过滤不可信来源流量
• 增加请求身份校验：要求厂商侧的推送请求必须携带双方提前约定的签名密钥/API Token，反向代理层优先校验请求身份合法性，校验不通过的请求直接拒绝，不会转发到内网应用
• 限制接口访问范围：根据厂商需要调用的推送接口路径，在反向代理层配置路由白名单，仅放行约定路径的请求，其余所有内网应用路径的访问全部拦截
• 开启全量访问审计：反向代理层留存所有访问日志，定期审计异常请求，出现攻击行为时可快速封禁对应来源

更高安全等级的替代方案 #

如果你们的业务数据敏感度较高，可以选择比基础反向代理更稳妥的方案：

• 专线接入：和合作厂商拉设点对点专线，所有推送请求走专用线路传输，全程不经过公网，安全性最高但部署成本也最高，适合核心敏感数据场景
• VPN隧道接入：要求合作厂商的推送服务先通过IPsec VPN或SSL VPN接入你司内网边界，再访问内部Web应用，安全性高于公网反向代理，但需要厂商侧配合完成VPN接入配置
• 云API网关中转：如果已有公有云部署，可将厂商推送入口放在云API网关，网关和内网之间走云专线或加密通道打通，网关层面完成全量流量清洗、身份校验、访问控制，进一步降低内网侧的安全风险

内容的提问来源于stack exchange，提问作者Jughead1217