零信任网络

长期以来,主流的网络安全观念是根据某类特征(如机器所处的网络位置、IP/MAC地址等)把网络划分为不同的区域,不同的区域对应着不同风险级别和允许访问的网络资源,将安全防护措施集中部署在各个区域的边界之上,我们熟知的VPN、DMZ、防火墙、内外网等概念都是由此而生的,这种安全模型今天被称为是基于边界的安全模型(Perimeter-Based Security Model)。

“边界安全”是很合理的想法,因为安全不可能是绝对的,我们必须在可用性和安全性之间权衡取舍,否则一台关掉电源不能对外提供服务的“服务器”无疑就是最为安全的。边界安全着重对经过网络区域边界的流量进行检查,对可信任区域(内网)内部机器之间的流量则给予直接信任或者至少是较为宽松的处理,以减小安全设施对整个应用系统复杂度的影响,以及网络传输性能的额外损耗,这当然是很合理的。不过,今天单纯的边界安全已不足以满足大规模微服务系统的技术异构和节点膨胀的发展需要。边界安全的核心问题在于边界上的防御措施即使自身能做到永远滴水不漏牢不可破,也很难保证内网中它所尽力保护的某一台服务器不会成为“猪队友”,一旦“可信的”网络区域中的某台服务器被攻陷,那边界安全措施就成了马其诺防线,攻击者很快就能以一台机器为跳板,侵入到整个内网,这是边界安全基因决定的固有的缺陷,从边界安全提出的第一天这就是已预料到的问题。在微服务时代,我们已经转变开发观念,承认服务了总会出错,现在我们也必须转变安全观念,承认一定会有被攻陷的服务,为此我们需要寻找到与之符合的新的网络安全模型。

2010年,Forrester Research的首席分析师John Kindervag提出了零信任安全模型的概念(Zero-Trust Security Model,最初提出时被称为“Zero-Trust Architecture”,即零信任架构),这个概念当时并没有引发太大的关注,但随着微服务架构的兴起,越来越多的开发、运维人员注意到零信任安全模型与微服务所追求的安全目标完全吻合。

“零信任安全”的中心思想是不应当以某种特征来自动信任任何流量,除非明确知道请求者(请求者不一定是人,更可能是另一台服务)的身份和授权情况,否则一律不会有默认的信任关系。在2019年,谷歌发表了一篇在安全与研发领域里都备受关注的论文《BeyondProd: A New Approach to Cloud-Native Security》(BeyondProd是谷歌安全框架的名字,从2014年起已连续发表了6篇关于BeyondProd的论文),此文中列举了传统的基于边界的网络模型与云原生时代下基于零信任网络的安全模型之间的差异,并描述了要完成边界安全模型到零信任安全模型的迁移所需实现的具体需求点,具体如下表所示。

传统、边界安全模型 云原生、零信任安全模型 具体需求
基于防火墙等设施,认为边界内可信 服务到服务通信需认证,环境内的服务之间默认没有信任 保护网络边界(仍然有效);服务之间默认没有互信
用于特定的IP和硬件(机器) 资源利用率、重用、共享更好,包括IP和硬件 受信任的机器运行来源已知的代码
基于IP的身份 基于服务的身份 同上
服务运行在已知的、可预期的服务器上 服务可运行在环境中的任何地方,包括私有云/公有云混合部署 同上
安全相关的需求由应用来实现,每个应用单独实现 由基础设施来实现,基础设施中集成了共享的安全性要求。 集中策略实施点(Choke Points),一致地应用到所有服务
对服务如何构建、评审、实施的安全需求的约束力较弱 安全相关的需求一致地应用到所以服务 同上
安全组件的可观测性较弱 有安全策略及其是否生效的全局视图 同上
发布不标准,发布频率较低 标准化的构建和发布流程,每个微服务变更独立,变更更频繁 简单、自动、标准化的变更发布流程
工作负载通常作为虚拟机部署或部署到物理主机,并使用物理机或管理程序进行隔离 封装的工作负载(就是Pod)及其进程在共享的操作系统中运行,并有管理平台提供的某种机制来进行隔离 在共享的操作系统的工作负载之间进行隔离

两种安全模型的对比以及其中引发的需求

这个表格其实相当于系统地阐述了零信任安全在微服务、云原生环境中的具体落地过程了,后续的整篇论文(除了介绍谷歌自己的实现框架外)就是以此为主线来展开论述的,由于论文原文写的较为分散晦涩,笔者对其中主要观点按照自己的理解转述如下:

  • 零信任不等同于放弃在边界上保护网络:虽然防火墙等位于网络边界的设施是边界安全而非零信任安全中的概念,但它仍然是一种行之有效的提升安全性的做法。在微服务集群的前端部署防火墙,把内部服务节点间的流量与来自互联网的网络攻击和未经授权的流量隔离开来依然是值得提倡的,这能够使其避开来自互联网的未经授权的流量和潜在的攻击,如最典型的DDOS拒绝服务攻击
  • 身份只来源于服务:以前传统应用都是部署在特定的服务器上,这些机器的IP、MAC地址很少发生变化,此时在安全角度来看系统是相对静态的。基于这个前提,安全策略才使用IP地址、主机名等作为身份标识符(Identifiers)。如今在微服务尤其是云原生环境中,虚拟化基础设施被大范围应用,这使得服务部署的IP、数量等随时都可能发生变化,因此,身份只能来源于服务本身,而不是服务所在的IP地址、主机名或者其他元素。
  • 服务之间也没有固有的信任关系:只有已知的、明确授权的调用者才能访问服务。这样可以阻止攻击者通过某个服务节点中的代码漏洞来越权调用到其他服务。如果某个服务节点被成功入侵,这一原则可阻止攻击者执行扩大其入侵范围,与微服务设计模式中使用断路器、舱壁隔离实现容错来避免雪崩效应类似,在安全方面也应当采用这种“互不信任”的模式来隔离入侵危害的影响面。
  • 集中、共享的安全策略实施点:这点与微服务的“分散治理”刚好相反,微服务提倡每个服务自己独立的负责自身的功能性、非功能性需求。而谷歌这个观点相当于为分散治理原则做了一个补充——涉及安全的非功能性需求(如身份管理、安全传输层、数据安全层)最好除外。一方面,要写出高度安全的代码极为不易,为此付出的精力甚至可能远高于业务逻辑本身,如果你有兴趣阅读基于Spring Cloud的Fenix's Bookstore的源码,很容易就会发现在Security工程中的代码量是所有微服务中最多的。另一方面,而且还是更重要的一个方面是让服务各自处理安全问题很容易会出现实现不一致或者出现问题时要修改多处地方,甚至有些安全问题如果不立足于全局是很难彻底解决的(下一节面向于具体操作的“服务安全”中将会详细说明),因此谷歌明确提出应该有集中式的“安全策略实施点”(原文中称之为Choke Points),安全需求应该从微服务的应用代码下沉至云原生的基础设施里,这也契合其论文的标题“Cloud-Native Security”。
  • 受信的机器运行来源已知的代码:限制了服务只能使用认证过的代码和配置, 并且只能运行在认证过的、验证过的环境中。
  • 自动化、标准化的变更管理:这点也是为何提倡通过基础设施而不是应用代码去实现安全功能的另一个重要理由。如果将安全放在应用上,由于应用本身的分散治理,这决定了安全也必然是难以统一和标准化的。做不到标准化就意味着做不到自动化,相反,一套独立于应用的安全基础设施,可以让运维人员轻松地了解基础设施变更对安全性的影响,并且可以在几乎不影响生产环境的情况下发布安全补丁程序。

谷歌认为零信任安全网络的最终目标是实现整个基础设施之上的自动化安全控制,服务所需的安全能力可以与服务自身一起,以相同方式自动进行伸缩扩展。对于服务来说,做到安全是日常,风险是例外(Secure by Default and Insecure by Exception),对于人类来说,做到袖手旁观是日常,主动干预是例外(Human Actions Should Be by Exception, Not Routine),这的确是很美好的愿景,但问题在于其代价是什么?代价有多大?很显然,零信任网络模型之所以在今天才真正严肃地讨论,并不是因为它本身有多么巧妙、有什么此前没有想到的好办法,而在于前文中提到的边界安全模型的”合理之处“,即“安全设施对整个应用系统复杂度的影响,以及网络传输性能的额外损耗”。以前的软件开发架构是很承受担零信任安全模型的代价的,只有在云原生时代,虚拟化的基础设施长足发展,可以将复杂性隐藏于基础设施之内,虚拟化的网络性能足够高,可以弥补安全通讯的额外损耗的前提下,零信任网络的安全模型才有它生根发芽的土壤。

综上,谷歌所诠释的云原生下的零信任安全,在引入比边界安全更细致更复杂安全措施的同时,也强调着自动化的重要性。换句话说,是既要保证系统中各个微服务之间安全通讯,同时也不削弱微服务架构本身的属性,如集中式的安全并不抵触于分散治理原则,安全机制并不影响服务的自动伸缩和有效的封装,等等。总而言之,所有这些都不是“大饼”,都可以实现,而且不会在底层基础架构的安全性和实现细节方面给微服务开发者带来额外的负担。

如何构建零信任网络安全是一个非常大而且比较新的话题,受文字篇幅所限,在这里就不做更多的展开了。下一节,笔者将从实践角度出发,介绍在前微服务时代(以Spring Cloud为例)和后微服务时代(即服务网格架构,以Kubernetes with Istio为例),具体是如何实现安全传输、认证和授权的,通过这两者的对比,我们能够更具体、更量化地体会到本文中所说的零信任安全模型的价值与权衡。

Kudos to Star
总字数: 3,600 字  最后更新: 8/26/2020, 3:24:39 PM