大家好我是二哥。
这篇我们聊聊零信任和SASE相关的概念。二哥主要介（科）绍（普）零信任这个概念的出现为什么是一种必然，当它已然出现后，从企业安全角度来看，为什么又直接催生了SASE的诞生。文章不涉及枯燥的代码和抽象的算法，大家当逛知乎一样看看吧。
1. 零信任为什么会出现
零信任英文是Zero Trust。Forrester于2010年提出零信任的概念，谷歌在2014年通过BeyondCorp（beyond the corporate network）浇了一把油之后，成功地火遍安全界。
1.1 基于网络边界的防护模式
在介绍零信任为什么会出现之前，让我们先把时钟倒拨回20年前。
那是一个基于default-trust network的时代。那个时候一家中大规模的企业一定会有一个规模不算小的IT部门以及机房。机房里面有什么呢？有支撑企业日常业务的各类服务：Mail服务、Web服务、FTP服务，如果企业涉及制造业，还会有ERP服务、供销管理服务等等。
这些服务都由IT部分负责日常维护，包括打补丁、升级、按计划扩容等工作。机房边缘还会有一个DMZ区域，用于运行一些对外提供的服务，如企业官网、邮箱服务等，DMZ区域的服务可以将外面的请求转发至内部。防火墙大家一定非常熟悉，它是IT从业人员的好伙伴，也是维护的噩梦。当然还有更多的服务没有画出来，如防止DDos攻击的设备、Web Application Firewall（WAF）等等，我就不一一举例了。
企业内部的人员或服务想要访问外部的网络，通常会经过SWG（Secure Web Gateway）。企业员工偶尔要在家办公，他首先需要通过V**连上公司的V**服务器，V**连接会将他和企业内部服务的通信数据打包，通过隧道传输。
这些机房里的服务加上DMZ、防火墙等软硬件基础设施构成了传统的企业网络边界。企业的分支机构和总部之间通过租用运营商的专用线路相连。
这样的模式被戏称为“城-池”防护模式。网络边界如同一堵带护城河的城墙，围住了一座城，留出了一个城门。城里的人可以自由移动，城外的人只能通过城门进出。而图1中V**就是这样的城门。
图 1：传统的基于网络边界的防护模式
“城-池”模式最大的风险是城里的人可以横向移动，lateral movement是MITRE ATT&CK术语，如果你关注网络攻击新闻的话，会经常看到这个词。还记得2020年12月报道的那起著名的SolarWinds攻击事件吗？此次网络攻击事件最晚开始于2020年3月，它导致了美国联邦政府数据泄露，还给成千上万的SolarWinds客户带来了巨大的麻烦。这次攻击中使用的策略就包含了使用伪造的凭据进行横向移动。
1.2 难以应付的爆炸式网络
时间来到2006年，这一年亚马逊发布了AWS，从此云计算席卷整个IT界，也彻底改变了企业的网络拓扑。
图 2: 网络边界被不断撕开、被突防示意图
如图2所示，这样的巨大改变使得划个边界来设防的IT环境被撕开了许多的口子，慢慢被切割成了若干个分散的子环境。使用者（员工、合作伙伴、顾问、供应商）；他们所使用的设备（手机、笔记本、台式机）；他们所访问的服务（SaaS 应用、内部应用、云设施、自行搭建的服务器）交织在一起使得所谓的网络边界形同虚设。
越来越多的企业慢慢将服务迁移到云端。罗马当然不是一天建成，也更不会在一天之内倒塌。在这个迁移过程中，出现了所谓的Hybrid模式，也即混合模式。企业既维护着on-premise的服务，也同时购买了更多的SaaS服务。
当Hybrid模式和WFH（WorkFromHome，在家办公）相遇的时候，一个有趣的问题发生了：假如一名员工如果在家办公，当他要从Office 365的OneDrive上下载一个很大的附件时，是通过V**将这个附件从企业内部网络绕一圈呢还是从家里直接连到Office 365？
很显然前者是相对安全，但又最不经济的一种做法。因为租用电信的带宽是很贵的，也很不容易扩容。当越来越多的人选择在家办公的时候，IT成本显然会急剧增加，体验却越来越差。所以后者是最好的方案，可是另外一个伴生问题出现了：安全问题该如何解决？
图 3：外部访问者访问SaaS服务使用V**或internet方式示意图
1.3 零信任的登场
如它名字所言，零信任从不信任任何请求，无论请求源起何处，也无论它的目的归于哪里。请求者无法看到整座城，相反他只能看到城里的一个酒楼或者驿馆。这其实类似所谓"Dark Cloud"的概念：用户只能看到该看到的些许服务，其它的不该看的，对他而言一概屏蔽。
零信任将关注的焦点从网络转移到服务本身。每一个服务都需要单独进行安全控制，这有效地阻止了横向移动，因为每个连接都是需要重新认证和授权，且是暂时性的连接。
零信任将网络安全的控制粒度细化到了每个服务层级，当然给IT的日常管理带来了更大的难度和更高的挑战。比如：
- 如何去基于每个服务进行认证和授权呢？
- 如何控制面向服务的暂行性连接呢？
- 如何在整体上进行audit以及事后分析呢？
那么业界给出的解决方案是什么样子呢？下面轮到SASE登场。
2. SASE长什么样子
前文我们提到企业的网络边界正以我们难以想象的速度被扩散、被撕扯、被突防。很显然，我们不可能再围一个无限大的企业边界出来。既然无法控制，何不就此放手呢？
大胆设想一个场景：一个企业的IT设施如果没有网络边界是什么样子的？我们拿图4和图1来对比，你会发现“网络边界”没有了。一个企业所使用的服务无论是on-premise的还是SaaS的，无论是位于自建的Datacenter还是位于Cloud，对所有访问者都是开放的。
你一定会大喊：那不等于开放大门让坏人任意进出了吗？当然放手不等于放任，没有边界不表示没有设防。SASE概念由此提出。
图 4：基于Zero-Trust的SASE架构图
SASE的全称是：Secure Access Service Edge。嗯，你看到这个名词的时候肯定会说一句：这啥玩意？每个单词我都看得懂，但合在一起到底在说啥？别急，二哥是个善解人意的人，合在一起不理解，把它们拆分一下就好理解多了：Secure Access 和 Service Edge。
我们拿生活中的一个场景来做个类比。假如你去一个豪华的小区拜访一位好友。很显然，你会被拦在门卫处，而且会被问到两个问题：你是谁？要去哪栋别墅？经过一番盘问后，门卫会给你发一个临时访客牌，并告诉你行走路线。看到没，这里的门卫相当于扮演了SASE的角色。
如图4所示，SASE和零信任搭配组成一个集中式的网络控制平面，它用于回答一个组合命题：谁，在何时，于何地，想要访问何种服务，是否准予访问又该如何控制这个访问？
2.1 Secure Access
Secure Access基于零信任来实现访问控制。零信任 = 总是检查，没有免检这一说。具体来讲，它借助于Identity-based Access和Context-based Access两员大将来干活。
Identity-based Access，顾名思义访问是基于身份认证的。每一次的访问都需要亮出你的身份，比如Office 365 teams的账号和密码。图4中画出来的Identity-as-a-Service用于对身份进行认证。当然除此之外，它还能提供更多的信息，比如此人的访问记录、历史通常登录某一服务的时间地点、访问权限等等。如图4所示，它可以为UEBA提供大数据分析的素材。
Context-based Access，是一个比基于身份认证访问更智能一点的概念。零信任除了验证账号密码是否安全外，还想更进一步了解更多的与这个账号所登录的所有设备相关的信息，比如最近一次访问是通过何种设备、于何地、使用的网络是什么？这些信息被称为Device Posture。可以看到这些设备态势信息比单纯的账号密码更丰富、更立体，也能更好地对访问者描绘出一个准确的画像。和Identy一样，context数据也能为UEBA提供大量的分析素材，同时UEBA的分析结论又能反馈到设备态势里。写到这里，二哥又想到了那个带反馈的“自动化和自动控制理论”模型。
如果一位大哥总是在美东时间白天从芝加哥登录访问一系列服务，他的登录地址会突然在半夜的时候出现在北京吗？或者他平时每天使用这些服务时，平均传输的数据量大概在1-2个GB左右，会突然下载几百个GB的数据吗？
答案是可能，但很显然出现了这样的行为总归是不正常的，二哥相信一句话：如果一件事你觉得不正常，解释再多也只是在自我安慰。图4中的UEBA会结合SWG/ZTNA对用户的行为和流量进行全方位的观察以及分析。对每个使用者总是会得出一个初始的基准行为。在这个基准附近上下浮动是正常的，但是大幅度偏离基准就是异常行为。
2.2 Service Edge
完成了认证是第一步，第二步是要决定是否授权这个请求，是否允许将这个请求接入到这个控制平面所管理的企业服务。
Service Edge涉及到两个词：Service和Edge。嗯，二哥好像说了句废话。这里的Service是指什么呢？它涵盖了企业所用到的所有的服务，无论是on-premise的还是SaaS的。而Edge则好比是这些服务的Broker和看门人，所有对这些服务的请求都要经过Edge。
我们都知道只要请求能被归拢到一个单一的出入口，就非常好控制了。所以Service Edge如同一个软件定义（Software-Defined）的Application Firewall。
如果我们回头看看这么多年IT的发展，会惊奇地发现我们正在努力将一切物理设施虚拟化、软件定义化。比如从物理计算到虚拟计算，从物理网卡到虚拟网卡、从物理网络到软件定义网络（SDN）等等。软件定义化则意味着可以控制的粒度变细，同时可弹性扩展的能力变强。我们像切蛋糕一样，按需要切分、使用物理设施。
图4中反复提到一个重要的概念：临时连接。它是在强调Service Edge作为背后所有服务的看门人，它可以基于rule所描述的访问控制，给访问者搭建一个临时的访问线路。
基于rule进行访问控制是Service Edge的标准配置，一旦它从UEBA、EDR、XDR等信息源那里得知这个访问者行踪可疑，它便变得智能起来，可以立即断开这个服务。CASB作为Cloud Access and Security Brokers，是一个很好的控制SaaS访问连接的服务，它既可以包括threat detection也可以包含incident response。
2.3 与其它服务集成
图4将SWG画在了靠近企业所用服务的位置，需要强调的是它也可以作为SASE的一部分以SaaS形式提供服务。SWG也叫Web Security Gateways (WSG)，一般用于企业outbound的WEB请求。
ZTNA是另外一个与零信任、Network Access相关的概念，它用于控制企业inbound的网络请求。图4中仅画出了service-initiated ZTNA这一种实现方式。我把两个容易引起混淆的概念写在这里，其余的留待感兴趣的朋友们自行谷歌研究：ZTNA与V**不同的地方在于，ZTNA可以将访问请求的控制粒度细化到服务层级，而V**只能控制整个网络层级。
限于篇幅，SASE与其它服务集成部分，我就不细讲了。当我们把它看成一个决策和控制平面，就会发现现有的Identity Tracking（如IAM）、Monitoring & Detection（如SIEM）、Protection（如EPP）和Response（如IR）领域的服务都可以和它对接，从而完成一个规模恢弘的全新的Risk Management系统。
Risk和Threat是两个不同的概念，前者是风险，后者是与安全相关的威胁。先有风险后有威胁。当风险成真即为威胁，攻击者可以通过各种手段将风险变成事实。身处安全行业多年，二哥非常强烈地感受到了目前安全产品的叙事焦点已经前挪至Risk Management领域。过往英雄辈出，未来已来，豪杰必将书写新的篇章。
2.4 SASE与边缘计算
你一定会好奇，为什么我会在这里提到边缘计算。莫急，我们继续往下看。
前文提到SASE是一个集中式的网络控制平面。这意味着所有的请求都会首先经过它。考虑到网络延迟、计算处理能力，其实将这个服务部署在离用户越近的位置越好。说到这里，你会想到什么？对，CDN。
但传统的缓存静态资源再分发的CDN可难堪此大任，实际上CDN已经从传统的cache角色转型到边缘计算（edge computing）上来了，甚至基于地理位置的优势提供了edge cloud compluting platform。
更要命的是CDN厂商会有自己的骨干传输网络，这就意味着如果基于边缘计算搭建了SASE，那cross-site之间数据同步将不需要跨internet，而是走自己的骨干网，想想这速度和稳定性就很美好。
Zscaler、Cloudflare都是正处于风口的公司。
3. 总结
零信任和SASE搭配组成了软件定义的网络边界（Software-Defined perimeter ，SDP），这个虚拟的边界围住了用户和企业使用的所有服务，包括on-premise、IaaS、PaaS、SaaS。它作为一个集中式的网络控制平面以SaaS形式提供服务，极具扩展性和安全性。连接控制平面的一端是访问者，与他的访问位置无关，连接平面的另一端是企业所有的服务，与这些服务运行在哪里无关。
零信任用于控制哪些用户可以访问企业使用的服务，而SASE则用于控制对这些服务的连接。简而言之：
- 无论请求是从何处发起，发往何处，首先需要进行认证和授权
- 如果请求是从企业所用服务往外，SWG是一个很好的控制节点
- 如果请求是从外部通向企业所用服务，则需要用到ZTNA
- CASB常被用来管理企业使用的SaaS服务，别忘记它
当然实际使用场景远比我的总结复杂。不过，我们的目的是科普，不是吗？
