0、 前言

去年搞了太多长文（认证系列、接入技术系列、HW攻防演练系列、SPA单包授权系列），有朋友同仁提醒我，希望不要搞太长，建议拆细一些，所以2023年尝试采纳，接下来会进行两个调整，一是问题拆细，二是结论先行。

本篇起缘于前不久和某大型金融安全团队交流时，聊到了安全SAAS化，包括边缘访问零信任-SASE,有过一些观点交换。

这个场景其实也是零信任经常被混淆的点，故将一些总结和观点分享出来，以作探讨。

如有偏差，敬请指正。

1、 基本结论

注1：观点类为个人观点，仅供参考；总结类的是客观的陈述或总结。

注2：下述观点类主要针对国内市场，海外(欧美为主)其云化进程是相对较高的，所以选择会有所不同。

1、观点1：受限于国内和欧美的云化进程差异和其他国情差异，针对中国国内，在未来3~5年内，笔者认为安全的SAAS化会有持续发展，但是在占比上，私有化(self-hosted) 仍会保持较大份额。

2、总结1：SAAS后化由于其云化特征，更有利于实现big data（大数据）汇集，以及算力汇集； 而且有利于复用云上的标准开发设施(如数据库中间件等)和网络设施（如CDN等）。

3、观点2：基于观点1，和总结1，从安全厂商视角：

1)、初创安全厂商会更倾向于基于SAAS进行安全产品开发，SASE、ZTNA相关厂商即其中典型。

典型原因考虑：

a)、All In SaaS或Primarily in SaaS（SaaS为主），以便和传统安全厂商错位竞争。

b)、云上开发设施和网络设施可标准复用，而且不受算力、内存和存储等资源限制，有助于提升新产品推出效率。反观私有化（self-hosted)部署，其设备资源（算力、存储、内存等）均是受限的，从客观上，需要对底层性能优化和稳定性有更高要求。

2)、综合安全厂商、传统安全厂商，则更容易倾向于SAAS化和私有化(self-hosted) 两条腿探索，且国内厂商通常Primarily in self-hosted（私有化为主）。

典型原因考虑：

a)、SaaS化确实在持续发展，属于新兴模态。毕竟鸡蛋不能放在self-hosted一个篮子里。

b)、SaaS化的大数据和算力汇集特性，对检测响应(Detect and response)类的DR产品确有效果上的增强作用。

2、 总结：SASE-对甲方客户的关键收益与挑战

SASE模式，对于甲乙双方，基于不同视角，其收益与挑战有所不同。本章节先从甲方客户视角分析。

2.1、 甲方可感知的关键收益(SASE)

1、 轻资产：甲方场内不需要再采购相关硬件设备资源，只需要按年订阅付费即可。

2、简化运维：甲方不需要再在场内维护大量的设备，网络侧、系统设备侧的维护人员被减少。当然，值得注意的是，策略运维（权限等访问控制策略、其他安全策略等）还是需要由甲方维护的，并不能完全由SASE厂商完全替代。

3、弹性易扩容：受益于sase云化特性，在云中心扩容机器、算力等资源非常便捷，所以如果临时要扩容，会变得容易。进一步，只需安全厂商在云端有充足资源预留，甚至可实现随时一键扩容。

值得注意的是，上述易扩容仅指云中心。如果涉及到甲方自建本地数据中心侧的扩容，则仍需面临部署调整connector反连器，用于打通和云端POP点的网络。

4、功能集成度优，易增购：受益于sase云化特征，以及SASE主张的全功能提供，SASE厂商通常会倾向于逐步完善能力，比如说从仅提供ZTNA，再补充提供SWG、CASB等其他关联安全组件，易于增购。

同时，这些组件（在单安全厂商自研的前提下）通常集成度更深。 原因：一家厂商集中开发，不需受到私有化(self-hosted)多组件需分开销售、分开部署运行的困扰。

5、SASE-POP点跨国CDN加速： 当甲方存在跨国访问（如国外员工接入到国内时），SASE厂商由于自建多个POP点，所以通常可以实现跨国CDN加速的效果，从而使得国外员工访问更快。

值得注意的是：在中国境内，由于网络质量优良、且带宽普遍较高，其实际作用并不明显，甚至可以认为在国内无加速效果甚至不排除有负向优化效果。进一步可参考本文4.1、谈谈SASE-POP加速小节。

2.2、 甲方面临的关键挑战(SASE)

凡事多为利弊参半，难以完美，需要进行选择，SASE自然也不例外，同样会面临挑战。

有必要说明的是，凡事并非非0即1：面临问题在所难免，关键是认识问题，建议甲方客户在面临选购时，可综合评估自身认可哪些收益、可接受及不可接受哪些不足，进行决策。

显然，SASE从推出到成熟需要周期，解决这些挑战需要周期。笔者相信随着发展通过SASE相关厂商和甲方客户、行业技术发展、行业监管等多方的努力，后续能逐步缓解或解决。 注：此句为笔者观点，本小节下述为客观总结。

2.2.1、 数据安全和隐私安全挑战：

由于SASE针对的是用户接入业务的场景，会涉及到至少四类数据的上云风险：

1)、身份类数据上云风险：主要是企业/机构中的员工、关联第三方的身份类数据，包括手机号码、组织结构、用户名等各个字段，用于实现认证和权限策略管理。

2)、策略类数据上云风险：比如说给员工授权了一些应用（业务系统）访问权限，以及相关的安全策略等数据。

3)、互联网上网流量上云风险: 员工访问互联网的场景，在SASE中通常会通过被称为Internet Access(IA)的组件,在PC终端上以Agent进行中间人明文引流并进行审计，其技术通常为在PC客户端导入CA证书，然后基于CA证书伪造网站的SSL证书，进行中间人劫持并实现明文解析。 注：本篇暂不详细解释该中间人明文引流技术，后续视情况开新坑描述。

这部分上云需要视各机构具体的安全接受情况而定，通常来说接受度尚可。

注： 隧道引流技术在这篇里有讲，但是技术性相对较强，请按需选阅。如果是想了解WEB代理（特指无端、免agent情况下）的引流，可以看这篇。值得注意的是，如果有端情况下，即使是WEB(HTTP/HTTPS)资源，也是可以走隧道引流技术的。

4)、内网访问流量：私网下的中后台办公和生产业务系统的流量上云风险：中后业务系统原本是内网访问，流量经过SASE云端+客户端Agent引流后，同样存在上云风险。

注1：上述中后台业务系统如之前总结，是指企业员工自用或关联合作伙伴等第三方使用的业务系统，包含办公类、生产类系统。

注2：随着机构/企业的业务发展，部分业务系统可能也会通过互联网发布，所以前述第3条“互联网上网流量上云风险"也可能会包含业务流量，需以甲方真实业务为准进行评估，上述仅描述的是典型情况。

2.2.2、 Conector反连器的可靠性挑战

虽然主要算力被云POP点所承载，本地主要是一个相对轻量的Connector反连器，但是Connector自身的可靠性仍然面临挑战。针对业务连续性要求高的甲方客户，Connector同样需要解决高可用问题（主备、双活、多中心等）。

2.2.3、 Connector反连器带来的多项安全挑战

Connector反连器带来了入站隐匿、安全敞口放大和审计、流量分析挑战。针对下述挑战，甲方客户需和SASE厂商一起，针对不同的网络结构，设计最优部署方案，缓解、控制风险。

入站隐匿：从技术角度，SASE-Connector反连器相当于在企业内网和外部互联网建立了一个合法的"隐匿隧道"。该模式导致从SASE-POP点过来的入站访问流量，对甲方是不可视的,访问源实现了入站隐匿。

安全敞口放大：基于Connector反连机制，一旦SASE-POP节点失陷，默认情况下企业/机构内网也等同于整体暴露。

流量审计困难：由于Connector默认会将所有访问内网的流量，全部变为Connector引流器的设备IP，会导致流量审计困难。针对7层资源，通常SASE厂商可以通过XFF(X-Forwarde-For)类似的方式插入身份。但3、4层资源处理会更为复杂。

NTA类流量分析设备对接困难： 同样由于所有访问内网的流量都变为Connector引流器IP，会导致NTA类设备对接困难。通常需要类似TOA(tcp option address)、Proxy Protocol、XFF等方式进行对接，但是对NTA类流量设备会提出更高要求（默认NTA类设备均通过源IP进行分析）。

注：上述问题中提到的技术方案，可部分缓解或在特定场景下解决问题，为避免文章复杂度，不在本篇讲述，后续可视情况单独开坑补充。

2.2.4、 多租户集中化带来的攻防安全挑战

由于控制面、数据面都集中在了SASE云端，其POP点、控制中心暴露于全网，安全集中点外部攻击风险会更为高启。

所以对SASE厂商的安全防护能力提出更高要求，甲方应谨慎选择，避免选择了开发安全投入和意识不足，会将安全当成功能产品、当成普通业务系统进行开发的厂商。 注：安全漏洞的技术成因，在之前有讲过，点击可查看。

2.2.5、 云资源专属和共享的差异选择挑战

此项主要针对的是中大型及以上的甲方客户会容易遇到。该类甲方客户，通常对于可靠性、不受其他租户影响的诉求较高，因此部分SASE厂商可选提供专属资源（如专属POP资源池），专属化带来的后果就是云化的资源共享带来的弹性扩容效果被削弱、或者成本上升，成本和弹性难以兼得，隔离和弹性难以兼得。 充分资源专属的情况下，则会导致SASE退化成为了一个第三方托管代维的半成品私有化(self-hosted）。

2.2.6、 高集成度带来的多个关联挑战

SASE功能高度集成，虽然带来了易增购的优势，但同样会带来的多个关联挑战。包括在前面也提到SASE边缘零信任是包括多个组件，包括并不限于SWG、RBI、CASB、NGFW等，实际上如DLP数据防泄漏、终端反病毒等均可包含在内

1)、多维度的非结构化数据和结构化数据过分集中的风险 ：这句话有点复杂，需要展开解释一下。 我们朴素地知道，数据越集中、量越大、维度越多，则其数据中值得挖掘的价值越高（丢失风险和损失则越大）。

那么如果采用了多个SASE组件，则可能会包括并不限于如下数据：

• 身份类数据：自有员工和第三方、合作伙伴员工的身份信息，如组织结构、手机号、用户名、口令等

• 策略类数据：应用（业务系统）访问权限，以及相关的安全策略等数据。

• 终端行为数据：PC上的文件操作、进程操作、访问业务系统等相关行为操作数据、具备DLP能力的还会采集IM聊天信息等。

• 终端环境数据：PC资产基本信息、上面安装的软件、运行进程等相关环境数据。

• 访问互联网的上网行为和内容数据：诸如访问网盘、搜索等行为数据，包含其数据内容

• 业务系统访问行为和内容数据： 用户访问业务系统的行为数据，如访问频次、访问时间、访问者、被访问业务系统等相关数据； 如果开启了明文中间人引流（HTTPS解开）、以及针对原本就无加密的 HTTP流量，还可看到访问内容。这些访问内容中，可能存在大量业务数据、会话凭证数据（包括部分老旧系统口令认证是不加密、或采用弱强度算法）。这会对甲方客户的业务改造进度提出挑战（如需解决，则需要将业务改为HTTPS，同时在整个链路中确保没有明文中间人引流，避免数据在云端被可视）。这也是值得甲方客户关注的一个问题点。

2)、SASE通常意味着单厂商(single-vendor)，和多厂商组合难以两全：SASE的核心能力天然是内聚的(该观点源于Gartner)，所以倾向于单厂商(single-vendor)，但显然单个厂商通常难以将多个组件都同时做好,所以，如若甲方客户试图选择多个其他厂商，和SASE中的某个单项组件进行组合，则很可能会遇到障碍。

注1：此条具体描述可参考本文第4.3、 为什么说SASE会天然倾向Single-Vendor?小节。

注2：SASE的单厂商(single-Vendor)说明，也可参考Gartner, 28 September 2022，《Market Guide for Single-Vendor SASE》。

3、 总结：SASE-对安全厂商的关键收益与挑战

3.1、 SaaS化对安全厂商的关键收益(SASE)

站在国内安全厂商视角，SAAS化自然是有其利的，其关键收益项如下：

3.1.1、 默认订阅制，有利于持续经营

安全走到现阶段，新产品新组件的出现越来越缓慢了，客观上导致国内安全厂商难以依赖过往靠新品、爆品的策略来获得持续营收。

后续在供给端，安全行业的主要发展趋势，逐步会变为订阅制、服务化。从行业发展中逐步也看到，综合安全厂商在私有化(self-hosted)安全产品上，也在往订阅制、服务化进行发展。

注意：上条含有笔者观点，并非纯客观总结，请综合判断，如有偏差，欢迎探讨补充。

3.1.2、 大数据增强DR检测和威胁情报效果

DR响应检测类安全产品已经进入力大砖飞时代，攻击数据在行业、全网具备一定的相似性，理论上数据越多，则有可能检测能力越强（注：必要而不充分条件，具体还看各厂商的技术实现）。

威胁情报效果同样也依赖于大数据、信息采集。

3.1.3、 云化有利于降低硬件成本

相比私有化(self-hosted)，通过云化资源复用、多租户间共享技术等，能够将单user（用户）、单endpoint（终端端点）的硬件成本降低。

值得注意的是：当前私有化(self-hosted)中，虚拟化部署也逐步普及，也开始逐步消除硬件成本。

3.1.4、 数据近厂商，更易监测和收到反馈，更容易保障安全效果

由于纯SAAS化下，安全数据贴近厂商端存放（云中心），可以通过一些技术+人工的方式，可以快速分析、接近实时或定期监测，发现异常能够及时响应。

相比之下，在私有化(self-hosted)部署时，通常需要在甲方客户处放置驻点服务人员，或定期上门协助响应处置，效果确实更难保障。

在self-hosted部署时，中大型甲方客户由于通常有驻场和定期上门，其效果还具有适当的保障。但是客观上，SaaS化对中等及以上规模的客户的安全效果更有利，确是利好（在self-hosted和SaaS化，以相同技术水平进行实现的情况下对比）。

注：针对该问题， 当前部分综合安全厂商也逐步在多项安全产品中提供 self-hosted+云端赋能的方式(Primarily self-hosted），也能缓解一定问题，但是客观来讲，效果确实始终难以与数据贴身（纯SaaS化）相比(同样是指self-hosted+云端赋能与纯SaaS化，以相同技术水平 进行实现的情况下对比）。

3.2、 SAAS化对安全厂商的关键挑战(SASE)

原则上而言，对甲方客户的挑战，即是对安全厂商的挑战。因为最终这些问题都需要安全厂商（供给侧）主要云落地解决。

3.2.1、 数据安全和隐私安全挑战

由于数据多个维度的差异性，针对关注数据安全和隐私安全的客户而言，SASE厂商往往需要通过多种方式，尽量减少有效数据上云，以缓解客户顾虑 。

1)、针对身份类数据数据：SASE厂商通常需要通过一些诸如数据脱敏等方式，尽量避免有效信息上云。但是 在同态加密技术（Homomorphic encryption）还不够成熟、不能广泛使用的前提下, 一些必要数据，终究是可以被解密还原，所以该项只能缓解，不能根治。

SASE厂商通常会根据不同甲方客户的不同安全要求，逐步适配优化改进。但是难以避免的是，在相当长一段时间内，仍然会存在高安全要求的客户，不得不被放弃。

注：同态加密（Homomorphic encryption）是一种可以针对密文进行检索、比较等操作，而无需解密为明文的技术。

2)、针对策略类数据：SASE厂商通常需要通过如分离部署（在客户私有网络部署下级控制中心）等方式，尽量减少不必要的数据上云。本项也同样存在第1条中的问题，从理论逻辑上，只是SASE厂商的自我设限，依然可以解密还原，面对高要求客户时会遇到质疑。

3)、针对内网业务系统访问流量：SASE厂商通常需通过类似于4层/3层代理的方式（即取消明文中间人解析），尽量减少不必要的数据上云。 本项存在的客观障碍是，HTTP流量依然会明文流经POP点，同时，取消中间人解析依然只是SASE厂商的自我设限。

注：此项不仅会使得SASE厂商自身的产品技术架构大幅复杂化（显然要实现脱敏、映射、分离等，会增加其复杂度），同时还会关联到行业技术、行业监管等多个方面。

注：互联网上网流量，通常甲方客户接受度高一些。

3.2.2、 Conector反连器的可靠性挑战

针对业务连续性要求高的甲方客户，SASE厂商需要解决高可用问题（主备、双活、多中心等）。

但是一旦开始部署可靠性方案，本地数据中心端就会变重，维护成本会上升。

所以如何在技术上找到一个合适的平衡，仍然是SASE厂商需要持续技术演进的点。

3.2.3、 Connector反连器带来多项安全挑战

反连器概要流量走向可参考本文4.2、 为什么说Connector入站是不可视的？小节。

总体而言，Connector反连器带来了入站隐匿、安全敞口放大和审计、流量分析几大挑战。

SASE厂商通常需要提供多种审计技术、POP可视技术，以向关注安全的甲方客户证明其安全性。

但是这通常需要一个过程，所以往往会从安全要求相对不高的客户开始演进，逐步加大难度。所以其真实挑战在于对客群选择和投入时机的把握。

毕竟在资源总是有限的现实世界中，SASE厂商是一开始就有充足的决心，去挑战最高安全要求的顶端客户？还是找到愿意接受一定安全瑕疵的甲方客户，这是一个很重要的抉择。

3.2.4、 多租户集中化带来的攻防安全挑战

此项SASE厂商只能通过时间+投入去解决，需要将安全内置到多租户架构中去，并持续投入、持续改进,难以一蹴而就。

尤其是对于初创厂商而言，在首先要解决存活的阶段，不排除会有所取舍，而选择承担一定风险，但具体视SASE厂商不同而有所差异。

3.2.5、 云资源专属和共享的路线抉择挑战

在本文2.2.2、 甲方面临的挑战(SASE)小节中，甲方客户针对专属和共享，更多是弹性和成本的选择。

但是对于SASE厂商而言，则意味着架构复杂度的提升、开发效率的下降，一旦操作不慎，还可能会引入规模性问题。

SASE厂商通常会根据自身的客群选择，来确认自身的投入策略。

3.2.6、 SASE功能高度集成带来的关联挑战

1)、多维度的非结构化数据和结构化数据过分集中的风险： 此项从SASE架构上，天然难以避免。SASE厂商一方面需通过技术改进进行缓解，尽量减少不必要的数据上云；其余削减不了的部分，则需通过技术外手段进行缓解，包括并不限于：行业政策、行业标准、行业云、行业监管等，以减少甲方客户顾虑，最终实现一个动态平衡。

2)、单厂商(single-Vendor)和其他厂商的组合障碍： SASE厂商通常会针对不同客户采取不同策略，受限于SASE内聚特性，多为产品策略，包括并不限于：

• 定向客户和场景选择：特定场景或产品能力匹配的客户，直接采用Single-Vendor模式。

• 正向增强策略：针对关键组件能力，不断划分客群进行识别区分，正向增强，使其越来越多组件能实现Single-Vendor。比如说某客群需要A+B两个组件，刚开始采购A组件，后续正向增强B组件达到客户要求后，再推广A+B组件。

• 放弃策略：针对确实不匹配的，也会主动或被动放弃。

4、一些补充说明

4.1、 谈谈SASE-POP加速

我们分为两个步骤来看，先进行国内延时实测，用于确认国内典型情况； 然后再基于实测数据画出图示，便于展示效果。

4.1.1、国内延时实测（无CDN)

linux大神曾经说过：Talk is cheap,show me the code，所以我们也动下手验证下。

1、为了验证，笔者临时创建了一个位于北京的VM，没有开启任何网络优化等策略

2、通过站长之家，进行PING速度测试。

https://ping.chinaz.com/82.157.144.68

结果如下图：可以看到，北京本地最快，低于1ms（不排除chinaz的检测节点就创建于腾讯云上，或离得足够近）、国内平均响应时间分别为电信32.4ms、多线23.2ms、联通21.4ms、移动32ms。

也就是说，在无需进一步优化的前提下，国内的网络质量，就是这么优秀。

4.1.2、SASE国内POP点真的能加速吗？

基于第1步的实测，以北京为例，我们认为国内平均延迟为30ms（实际多线为24ms)。

如果SASE厂商的POP点并不足够多，从下图可看出，假设终端1到某POP点是20ms，该POP点到北京是25ms，两者相加可能会变为45ms，从而大于其直达 延迟。

乍一听和之前所认知到的有所差异，但是回想一下数学中有提到的，两点之间，直线最近，或许就能豁然开朗了。

但是注意了：这里有个前提，就是网络是较为健康而平坦的，没有瓶颈、没有堵车。而这点恰恰是中国境内能保障的。

还可类比道路，如果直线道路是坑坑洼洼、超级堵车的，那么绕道不堵的、平坦的路线（虽然更远）就有可能比直线更快。如果直线路径、最短路径是顺畅的，那么它就理应是最快的。

但是这个问题是否可解决呢？

笔者认为，只要SASE厂商在国内部署合适数量的POP点，就能大幅缓解该绕路问题。

如果能每个城市一个POP点，且POP点自身无堵车（带宽瓶颈等），则能基本认为消除该问题。

综上，笔者认为在国内运营商主干网络无明显瓶颈前提下，网络道路四通八达，SASE厂商在国内POP点的效果主要是避免产生不利影响，并无实际加速效果。

注：4.1.2、SASE国内POP点真的能加速吗？，笔者是基于4.1.1的测试数据假设推导的，未经过充分的1:1实测验证。如果有实测数据证明，推测和实际有偏差，敬请联系指正。

4.2、 为什么说Connector入站是不可视的？

如下图。下图红色虚线，是访问内网业务系统的流量，其经过了Connector代理->SASE-Connector反连器，最终访问到OA系统。

值得注意的是，Connector代理和Connector反连器是反向通信（出站嵌套入站），在DMZ区Firewall上是看不到任何入站数据的。

最终现象：

1、在下图Firewall中，只能看到Connector->云端Connector代理的出向连接。

2、在下图NTA设备中，只能看到Connector(172.16.1.3)连接各个业务系统(如OA系统)的连接请求

4.3、 为什么说SASE会天然倾向Single-Vendor?

参考Gartner, 28 September 2022，《Market Guide for Single-Vendor SASE》，SASE表1中，包含核心能力7项、推荐能力10项。这17项能力基本囊括了边缘访问的方方面面。

而Gartner自身也说，The capabilities in Table 1 should be cohesive（表格1中的能力应当是内聚的）。

笔者补充观点：架构一旦SAAS化后，支持多租户、支持了多种安全组件（SWG、CASB、ZTNA等），其技术架构、网络架构(POP点等）天然变得庞大而离散（但适配于云化）。在该情况下，和其他厂商对接自然就开始出现障碍。受限于篇幅，不详细展开

4.3.1、国际上典型的Single-Vendor厂商

下图来自Gartner, 28 September 2022，《Market Guide for Single-Vendor SASE》。

5、结语

笔者：本来尽量想写短篇，然而事与愿违，写到后期一看，已然是一篇长文。。难道是我拆分文章的姿势不对？陷入了深深的思考。

部分参考：

同态加密：https://zh.wikipedia.org/wiki/%E5%90%8C%E6%80%81%E5%8A%A0%E5%AF%86

Gartner, 28 September 2022，《Market Guide for Single-Vendor SASE》