它们的出现是必然。一文读懂零信任和SASE

大家好我是二哥。

这篇我们聊聊零信任和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服务,别忘记它

当然实际使用场景远比我的总结复杂。不过,我们的目的是科普,不是吗?

本站文章资源均来源自网络,除非特别声明,否则均不代表站方观点,并仅供查阅,不作为任何参考依据!
如有侵权请及时跟我们联系,本站将及时删除!
如遇版权问题,请查看 本站版权声明
THE END
分享
二维码
海报
它们的出现是必然。一文读懂零信任和SASE
这篇我们聊聊零信任和SASE相关的概念。二哥主要介(科)绍(普)零信任这个概念的出现为什么是一种必然,当它已然出现后,从企业安全角度来看,为什么又直接催生了SA...
<<上一篇
下一篇>>