使用 Identity-Aware Proxy 还需要 VPN 吗？

假设是这样的：只要有一个懂身份的代理挡在内部应用前面，VPN 就只是装饰，客户端可以撤掉。这只在一种狭窄情形下成立，即人在浏览器里使用的交互式 HTTPS 应用；换到别处就会静默失败。代理授权的是一个针对某项资源的请求；VPN 则把客户端放进网络作用域，这两条边界很少重合。在停用隧道之前，请比较员工真正执行的操作，而不是图上的产品标签。

两道门授权的是不同的东西

应用网关决定这个请求、这个身份能否到达这项受保护资源。Google 的Identity-Aware Proxy 概览描述的正是这种形态：位于 HTTPS 应用之前的中央授权层，由 IAM 角色驱动。边界是资源，访问单位是请求。路由型 VPN 做的事更粗也更宽：把客户端放进一个已定义网络作用域，之后仍由应用决定该客户端能做什么。

两种模型都不蕴含对方。穿过网关并不说明能读某条记录，身处网络也不说明获准行动。

代理不覆盖、而 VPN 覆盖的部分

SSH 会话、数据库客户端、消息代理，以及任何浏览器都不会打开的内部主机名，不会仅仅因为存在 Web 代理就变得可达。它们各说各的协议，各自要么需要自己的认证路径，要么需要一条承载它的网络。这正是人们在迁移第一天发现缺口的地方，通常来自一位笔记本再也解析不了主机名的值班工程师。

反向的缺口同样真实。把客户端放进子网的 VPN 并不认证里面的人，而该子网上被入侵的设备会继承网络允许的一切。如果要求是带可审计身份的逐请求授权，光靠路由做不出来。多数组织最终两者并用，真正有意思的问题是哪些资源各自可以站在前面。

客户端工作流比架构图更能决定结果

带重定向和偶发 MFA 挑战的浏览器登录，对点书签的人是良好体验。cron 任务、CLI 或构建代理没有浏览器，无法回答交互式提示，因此需要一份写明的非交互路径，或者那条隧道。发现这项要求通常发生在设计获批之后。

先数客户端，再数应用。一个仪表盘可以服务一百个人；一个数据库端口可以堵住整个团队。

设备状态不是任何一道门的属性

安装 VPN 客户端不等于合规检查，基于浏览器的设计也不自动等于无法遵守受管设备策略。两者都可以接入状态信号，也都可以在没有信号的情况下部署。要问清存在什么强制执行、策略归谁、违反策略的设备会怎样，而不是从产品形态去推断。

撤销访问也需要同样的谨慎。在代理里删除组成员关系，与为隧道吊销证书，是两条时延不同的操作，其中一条在离职时通常被忘记。

在停用任何东西之前，找出替代路径

代理后面的未受保护源站、绕过它的第二个主机名，或旧设计留下的宽泛专用路由，会决定哪道门真正生效。请用真实客户端而不是控制台，测试一次允许和一次拒绝的操作，并用一台从未登记过的设备再测一次。真正说明这道门有没有用的，正是被拒绝的那个用例。

然后写下交接：登记、更新、撤销访问，以及凌晨 2 点被锁在外面的人的恢复路径。删掉提示或客户端应用，只是把责任在团队之间挪动，并没有消除责任。

如果你本周要做决定，请从操作清单开始而不是产品清单，标出浏览器能完成哪些，其余部分则去论证那条仍然存在的网络访问。