SASE 与 VPN：架构差异与取舍

当 sase vs vpn 这个问题被拿到会议上时，多半是因为有人看了一页满是缩写的厂商幻灯片。坦率的出发点是：VPN 只是一件事，即两点之间的一条加密隧道；SASE 则是一类云服务，把好几样东西打包在一起，隧道只是其中很小的一部分。

本文把两者当作架构来比较：看流量到底怎么走，每种设计让什么事变容易或变难，以及买下一整套服务时你要拿什么来换。它适合需要为公司、学校或有多个地点的团体出主意的人。零信任的总体思想已经在 零信任与 VPN 有何不同 里讲过，这里不再重复，也不会推荐任何厂商。

SASE 打包了什么，用大白话说

SASE 即 Secure Access Service Edge，最初是作为一种“模式”被命名的，而不是某个单一产品。想法是把网络和安全从办公室机房里搬出来，变成运行在许多云端位置、靠近用户的服务。实际中，一个产品通常包含下面部分或全部内容：

• 广域网络。 分支机构、数据中心和云之间的连接，常通过 SD-WAN 实现。如果你只关心这一块，它有单独与 VPN 的对比。
• 安全网页网关。 过滤和检查网页流量，拦截已知恶意站点，执行上网规范。
• 云应用管控。 了解员工在用哪些云应用，以及在里面做了什么。
• 零信任网络访问。 按应用授权，而不是整个网络。
• 云防火墙。 以服务形式提供的防火墙规则，而不是柜子里的一台设备。
• 数据防泄漏。 识别敏感内容通过浏览器或上传离开的规则。

VPN 不提供检查、过滤或应用识别，它给你的是一条加密通路，经过配置后还有一组有限的路由。两者并不是在同一条赛道上竞争，所以那些要分出高下的对比文章往往站不住脚。

流量路径有何不同

理解架构差异最清楚的方法，是跟着一个数据包走一遍。

有总部的传统 VPN。 在家的员工打开一个云端文档工具。如果 VPN 设成所有流量都经过总部，请求会从笔记本到办公室网关，穿过办公室防火墙，从办公室的出口上网，再到云服务；回程原路返回。这有时叫“发夹”或“绕路”。它简单，也让办公室防火墙能检查一切，但增加了距离，并把办公室的线路放在每一次云端操作的中间。

分流（split tunnel）VPN。 员工通过 VPN 访问内部系统，其余流量直接上网。访问云工具更快，但办公室防火墙不再看得到这些流量，保护措施必须转移到笔记本本身。这一点在 什么是分流隧道 里有说明。

SASE。 笔记本把流量送到最近的服务节点。该节点执行策略，必要时进行检查，再把请求转发到云应用，或通过连接器转到私有应用。总部不在互联网流量的路径上。分支机构通过一台小设备或一条隧道以同样方式接入。结果是，安全策略跟着用户走，而不是绑在建筑上。

实际差异体现在两处。对以云为主的团队，SASE 能缩短路径，减少对办公室单条线路的依赖。对系统大多集中在一处的团队，多绕一个服务节点反而可能比直连隧道更远。

并排看

问题	普通 VPN（基于网关）	SASE（打包的云服务）
它是什么	加密隧道加路由	网络与安全功能的组合
策略在哪里	网关和办公室防火墙	云服务中，在用户附近执行
互联网流量路径	经办公室，若分流则直连	经最近的服务节点
应用识别	很少或没有	核心功能
网页流量检查	仅当办公室防火墙做时才有	内置，通常包含解密
分支机构连接	站点到站点隧道，手工管理	通过服务统一管理
运维模式	你自己运营硬件或虚拟网关	你负责策略，厂商运营基础设施
对厂商的集中度	低，部件可互换	高，多种功能集中一处
典型买家	中小规模、地点少	地点多、云服务多、远程员工多

“对厂商的集中度”这一行很少出现在幻灯片上。把网络、网页过滤、远程访问和数据管控都交给一家供应商，会让运维更简单，同时也把大量信任押在一家公司身上。

实例：一家区域物流公司

设想一家物流公司，有一个总部、八个仓库、120 名员工，以及越来越多使用手机的司机。系统包括云端运输管理工具、云端邮件与文档套件，以及一套运行在总部的老仓储系统。

改造前。 每个仓库都有一条通往总部的隧道，仓库的全部上网流量都经过总部防火墙，因此仓库员工访问云工具要走很长的路。总部线路一繁忙，所有仓库都跟着变慢。仓储系统运行良好，因为它就在隧道所连的那个网络上。远程员工用 VPN 客户端，一切流量都经办公室。

SASE 方案。 每个仓库装一台小设备，连接最近的节点。上网和云流量直接从那里出去，并应用网页过滤和策略。远程员工和司机用同样工作方式的客户端。仓储系统通过私有应用连接器发布，只有需要的人能访问。总部线路现在只承载办公室自己的流量。

实际变化。

• 仓库员工访问云工具的路径变短，由总部线路造成的日常延迟消失了。
• IT 团队只需写一次策略，仓库、远程员工和司机都适用。
• 站点故障更容易隔离，因为仓库设备上网不再依赖总部。
• 公司现在依赖厂商的节点是否靠近各个仓库，也要把自己的设备和身份管理做好。

没有变化的部分。 如果仓储系统本身很慢，SASE 修不好。如果司机的账号被钓鱼，SASE 可以限制损失，却防不了那次失误。

你要接受的取舍

买一整套服务就是一次交易，要清楚自己放弃了什么。

• 组织内部的隐私。 为了对加密的网页流量执行策略，很多服务会在途中用受管设备信任的证书进行解密。这是现代 TLS 下检查流量的方式，TLS 1.3 规范中有描述，应当用平实的语言告知员工。
• 到服务节点的延迟。 如果最近的节点离仓库很远，SASE 可能比直接上网更慢。在断定它会更快之前，先问清楚节点位置。
• 锁定。 策略、设备配置和日志都以厂商的格式存放，日后迁移要花时间。
• 成本模式。 通常按用户或按站点持续付费，并随人数增长。对小团队来说，你已拥有的网关也许更便宜。
• 技能。 写好策略需要时间和理解。配置不当的套件会带来虚假的安全感。
• 单点依赖。 服务一旦中断，或身份系统出问题，工作可能停摆。

这些并不意味着 SASE 是个坏主意，只说明它是一项有价格的决定。

VPN 仍然是正确答案的时候

在这些情况下，无论是远程访问型还是站点到站点型 VPN，仍然合理：

1. 只有一两个地点，大部分系统集中在一处。
2. 员工主要使用少数几个需要完整网络访问的内部系统。
3. 想要一个简单易懂、一个人就能维护的方案。
4. 需要访问实验室设备、工业设备或不适合代理模型的老系统。例如从办公室访问家里的文件服务器，就遵循 家庭站点到站点 VPN 中的模式。
5. 预算紧张，团队不需要流量检查或云应用管控。

VPN 本身也是许多 SASE 服务内部的组成部分，所以它并不过时，只是工具更窄。如果你为一家很小的企业选型，小企业 VPN 该看什么 比一本 SASE 产品目录更切合实际。

向厂商提问的清单

如果决定考察 SASE 产品，带上一份简短的问题清单，而不是只靠幻灯片。

1. 你们的服务节点在哪里？我的用户会连到哪一个？
2. 如果最近的节点不可用，用户的流量会怎样？
3. 哪些流量会被解密？能否排除银行、医疗等类别？
4. 日志存在哪里、保存多久、谁能访问？
5. 如果我要离开，怎么导出策略和日志？
6. 客户端在笔记本上做什么，在手机上做什么？
7. 哪些私有应用和协议可用，哪些不可用？
8. 如何计费：按用户、按站点，还是按带宽档位？
9. 如果我的身份系统宕机，应急访问方案是什么？

答案比功能列表更重要。对日志或解密含糊其辞的厂商，其实已经在告诉你些什么。同样的审慎适用于任何服务商，所以即使你从不购买消费级产品，VPN 信任模型 也值得一读。

不必一次性切换的分阶段做法

1. 摸清流量。 记录一周用户去向：多少是内部，多少是云，多少是普通网页。
2. 先打好基础。 多因素认证、设备更新和干净的用户清单，无论选哪种架构都有益。
3. 先试一项功能。 许多组织先给一个群体启用网页过滤或私有应用访问，而不是整体替换。
4. 衡量。 对比前后的页面加载时间、通话质量和服务台工单数量。
5. 逐站点推广。 先迁一个仓库，再迁下一个，在新路径被证明可靠之前保留旧隧道。
6. 每年复查。 检查策略、成本，以及厂商是否仍然合适。

CISA 零信任成熟度模型 可以帮助你判断哪些方面应优先。

常见错误

• 把 SASE 当成装好就完事的产品，而它其实是需要运营的架构。
• 买下所有模块，实际只用了两个。
• 保留全部旧的宽松规则，再把新服务叠上去。
• 忘记告诉员工流量会被检查。
• 没有从最不方便的站点测试体验。
• 以为新套件能解决弱密码或没打补丁的笔记本。
• 把 SASE 与个人 VPN 混为一谈。个人 VPN 保护的是你在自己无法掌控的网络上的流量，是另一个话题。

总结

VPN 是一条加密隧道。SASE 是通过云交付的组合服务，把网络与安全功能结合起来，并把策略放到靠近用户的节点上。SASE 能缩短以云为主的团队的路径，让小型 IT 团队管理许多站点，但也带来对厂商的依赖、对流量的检查和持续的费用。地点少、需求简单、有老旧系统时，VPN 依然是更好的选择。请根据你的应用和人员实际所在的位置来选。

如果你需要的是给自己设备用的个人 VPN，而不是公司架构，随时可以看看 价格页面。