零信任原生安全：超越云原生安全

【编者的话】本文从信任的定义开始，探讨（零）信任的内涵，然后分析云原生安全和零信任安全的关系，云上的成功会将零信任原生安全融合更多安全防护手段，应用各类复杂应用场景。

引子

一个好的安全体系的前提是为合法主体建立信任关系，通过信任在保证业务的前提下降低安全成本，在运行时及时检测并消除非法主体的恶意行为，所以信任是网络安全的前提要求。笔者在2012年于《计算机学报》上发表过一篇 信任机制的文章 ，后来接触了云安全联盟CSA提出的软件定义边界SDP（现在被认为是零信任网络访问的一种典型流派），在2014年11月的CSA云安全高峰论坛的晚宴上与CSA的CEO Jim Reavis有所探讨，所以自认在信任机制方面有所研究。

从业界今年的发展来看，无论是Gartner认为信任和弹性是自适应安全的两个原则，还是“零信任”理念成为业界热议的流行词，都说明大家已经反思简单堆砌安全机制已经无法抵御日渐复杂的应用场景和攻击团伙，所以回归安全的本源，思考如何构建信任体系，成为当前一种独特的现象。

本文尝试从信任的定义开始，探讨（零）信任的内涵，然后分析云原生安全和零信任安全的关系，云上的成功会将零信任原生安全融合更多安全防护手段，应用各类复杂应用场景。

信任模型

Wikipedia对信任（Trust）的 定义为 ：一方（信任方）在未来依赖另一方（被信任方）行动的意愿。假设给定三方A、B、C，三者之间都有交互，如下图所示。

图1 信任度模型

那么信任是指主体A对主体B未来发生行为action(B)的依赖意愿，这里有两层含义：

1. 信任是对主体B是否会做行为action(B)的判断，包含了对主体本身B和其行为action(B)的双重判断。其中主体A对主体B的判断为信誉，记为Reputation(A, B)。
2. 信任是用于判断主体B未来的行为的可能性（B以前的行为都已经成为A的经验）。说明信任度本身是主观的、不确定的。模糊数学、证据理论等都是是支撑信任度量的数学模型。

那么主体A对B的信任度Trust(B,A)形式化表述为：

Trust(B,A)=t({action (B)}, Reputation(B, C))，其中t为信任评估函数。

可见，主体A对B的action(B)行为的信任是结合了A对B的历史行为的观察{actions(B)}、第三方（如主体C）对其信誉评价Reputation(B,C)的综合评估。事实上，信任度的度量会更复杂一些，需要考虑到观察行为（即证据）的可靠度，以及信任度随着时间推移衰减等因素。

而信任机制在应用时，根据不同的场景和需求，会有多种形态，如IAM、访问控制、边界控制等，具体产品就更五花八门，但核心上看，信任管理有四个要素：

1. 主体身份属性确认，即Identification
2. 资源的属性确认，即Attribute Enumeration
3. 主体对资源操作的授权，即Authorization
4. 操作控制，即Enforcement

图2 信任机制表示

行业内主流的信任管理机制都是采用了确定性的信任评估方式,设置后长期不变，虽然简化了策略制定、系统运行时机制，但没考虑到上下文变化，是造成现在网络安全事件频发的根本原因之一。

从主体身份的角度看，主体身份是可能会被假冒的，或合法主体在某些条件下作恶。更具体可参考密码验证登陆系统的操作，虽然系统安全策略要求用户设置复杂的密码，并定期要求更新，也不能完全假定用户是可信的。攻击者可以使用钓鱼、拖库等常见的攻击手段，获得用户密码；此外，用户虽然更新的密码复杂，但为了便于记忆，每次使用的密码存在规律，也容易被破解。所以，现在越来越多的IAM方案采用无密码（Passwordless）、多因子认证MFA、生物技术Biotech等方式。

从资产属性的角度看，防火墙策略中的五元组目的地址所指示的就是被访问资源，但随着业务变更等环境变化，资源的属性也会随之变化，但如果安全策略没有及时更新，还是以之前的网络地址作为五元组目的地址，显然会出现访问控制失效。事实上，在很多缺乏有效安全运营的大机构，这种现象是非常常见的。

现在在一些以风险为基础的模型中，如Gartner的自适应访问控制，安全策略需要根据主体行为等上下文动态调整，这也体现了信任是主观、动态、不确定的。

从策略控制点的角度看，例如云中的访问控制，随着虚拟机迁移，主体和资源属性、安全策略都没有发生变化，但资源所在的宿主机变化了，如果还在原宿主机的虚拟网络上执行策略控制，显然无法控制主体的访问行为了。又如云中虚拟子网内部的流量不会经过虚拟路由器或虚拟防火墙，如果将这些虚拟设备作为子网内部的访问行为的策略控制点，也是不合适的。可见，访问控制点应根据主体和资源间的访问路径进行动态部署，且其数据平面的处置应与控制平面的安全策略一致。

所以，一个好的信任管理机制，在控制平面，需要保证主体、资源属性与安全策略在运行过程中保持一致（aligned），在数据平面，操作控制点能时刻在主体和资源的访问路径上。

真的有零信任吗？

前面我们分析了信任管理，那么“甚嚣尘上”的零信任又是什么呢？

我们不禁要问，世界上到底有没有零信任？

答案是：“没有”，也“有”。

首先，从人性的角度看，世界上“没有”零信任的。信任亘古以来就是一切人类重要活动的前提，论语有云：人无信不立，业无信不兴，国无信则衰。我们经常看到，当一个机构的安全管理者认为业务存在风险时，动辄限制合法用户的访问权限，或将业务功能降级，以期满足风险合规的要求。但这种做法没有区分合法用户和恶意攻击者，一概认为用户是不可信的，从结果上看约束了业务的正常开展，降低了企业各项业务的收益。

其次，从技术的角度看，世界上是“有”零信任的。至少到现在为止我看到区块链及其之上的应用可以是零信任的。正因为区块链有去中心化的共识机制，能让上层的智能合约全局一致地执行，从而支撑了事前无信任或弱信任的多方进行复杂交易。可以说，共识算法是公有链零信任的基础，但这样的零信任基本是建立在机器与机器之间的关系，显然不是当前业界在谈的“零信任”。以人为本的业务的信任机制还应是基于传统的信任模型。

零信任的技术路线

所以从上面的分析可见，“零信任“从字面上看是有误导性的，世界上不存在完全不信任任何主体的业务，所谓“零信任”安全，更准确的说应该是“默认不信任，时时处处验证”安全。

从技术上看，要做到信任管理，或在身份上下功夫，或在控制上下功夫，所以现有业界的零信任方案必定落到某个具体的技术领域内，如身份管理、访问控制、区域隔离、应用安全等。

身份和权限管理（IAM、IDaaS和PAM）作为信任的第一个环节，也很自然的得到了业界重视，例如Cisco收购的 Duo Security ，就是IAM起家，并融入到 Cisco的零信任方案 中。此外，如Centrify于2018年底将IDaaS业务拆分为独立的公司Idaptive，也在套用零信任的概念，还有国内的九州云腾也有相似的方案。

在主体执行动作时，对主体权限和行为进行判断，最常见的是网络访问控制，这类零信任方案统称为零信任网络访问（ZeroTrust Network Access，ZTNA），细分的流派有CSA SDP和BeyondCorps两类。不过Gartner在最新的报告中将这两类又统称为软件定义边界SDP，所以文中将前者称为CSA SDP，表示是最早由CSA提出的狭义SDP流派。

CSA SDP见下图，认证请求是由客户端发起的，控制器经过访问控制策略判断下发指令，最终Gateway根据指令放行或阻断。

图3 CSA SDP

BeyondCorps的路线最早见Google BeyondCorps项目，其流程见下，认证请求是由用户访问的服务发起的，控制点也在服务侧，所以该服务的角色就是代理。

图4 基于代理的ZTNA路线

从效果看，这两种技术路线都是将后面的应用隐藏，除非用户提供了自己的身份和访问资源，否则用户是无法访问应用的。从部署上看，CSA SDP需要客户端安装Agent，所以环境要求较高，目前主要是应用于替代VPN的场景中，这类公司较多，如Cyxtera、MetaNetwork、Verizon等。

从结果看，“零信任”与隔离有很大的相关度。一些云厂商，借助微隔离技术可天然按照不同粒度隔离业务，也在提零信任。例如VMware在NSX产品中提用微隔离减少攻击面，尽管这种技术在零信任概念火起来之前就存在很久了。所以，这就将我们的讨论引到了一个很有意思的方向：零信任和云计算安全的关系。

云计算安全：天然零信任

云计算业务安全天然需要零信任

值得注意的是，虽然国内外的云计算发展趋势不同，但公有云市场占有率不断提升、企业上云是共同的趋势。在这一趋势下，企业的关键业务会越来越多地部署在公有云上，那么其暴露面和攻击面势必变大，如SDP等零信任的技术可以将一些企业内部业务部署到公有云上，但这些业务对外并不暴露，攻击者无法从互联网上找到这些业务，但合法用户却可以通过客户端或代理经过验证后访问这些内部业务。

此外，随着SDWAN的火热发展，企业的分支机构通过uCPE进行互联，边界设备大大弱化，相反如Zscalar等SDWAN安全厂商在运营商网络中提供了各种云化的安全能力，企业员工可在任意地点，任意终端登录企业各地分支机构的服务，那么在如此复杂的网络环境中，能否将服务暴露面降到最低，做到全局一致的访问策略？今年SDWAN安全厂商也加入零信任安全中。

此外，前面也提到，云中虚拟资源迁移、业务变更频繁能到秒级，所以安全策略能否跟随业务，业务间的隔离粒度能否到最小，也是零信任的原生需求。

从这些角度看，可以说云计算安全是催生零信任最早的行业推动力。

云化基础设施为零信任提供强大的能力

云计算系统的最大特点是所有资源虚拟化和软件化，平台集中化。其中，如认证和访问控制机制是云计算系统原生提供的，如Openstack提供了Keystone认证服务、安全组、防火墙即服务，Kubernetes支持多种认证、授权机制和网络策略，所以这些云平台控制平面和数据平面都是原生支持零信任的。

具体的，在OpenStack的管理控制平面，所有用户或组件对资源的操作都需要先经过认证组件Keystone的认证，认证后获得凭证token，然后每次执行操作时附上token，此时再判断主体是否有权限执行该操作。

export OS_USERNAME=admin

export OS_TENANT_NAME=admin

export OS_AUTH_URL=http://controller:35357/v2.0



#keystone token-get

+-----------+----------------------------------+



| Property  |             Value                |



+-----------+----------------------------------+



| expires   |      2013-05-07T13:00:24         |



|    id     | 5f6e089b24d94b198c877c58229f2067 |



| tenant_id | f7e8628768f2437587651ab959fbe239 |



| user_id   | 8109f0e3deaf46d5990674443dcf7db7 |



+-----------+----------------------------------+

然后就可将5f6e089b24d94b198c877c58229f2067放于X-Auth-Token字段，通过curl发送请求即可访问其他相关资源。由于所有操作都需要先经认证再根据token授权，所以管理平面的信任是完备的。

在Kubernetes管理控制平面，Kubernetes原生支持 RBAC授权 、 ABAC授权 和 节点授权 等授权机制。管理员或服务通过证书进行认证，然后系统根据角色或属性判断主体是否能够对资源进行操作。

如下面命令可建立一个可对Pod执行“get、watch、list”的角色pod-reader：

kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

云计算系统数据平面的访问会涉及计算资源的隔离和访问控制，资源隔离毫无疑问是虚拟化天然的特性，所以VMware称其微分段就是零信任的；至于访问控制，则分为服务暴露和内部网络访问两部分。

在VPC环境中，虚拟机如无分配浮动IP，外部是无法访问VPC内的虚拟机，又如Kubernetes只是新建了Pod或Deployment，外部也是无法访问该Pod上的业务的。所以云计算资源暴露面默认是没有的，从而避免了绝大多数来自互联网上的威胁。至于当Openstack为虚拟机分配了浮动IP、Kubernetes为Pod分配了Ingress或NodePort服务后，这些云资源对外提供服务，用户可在外访问，出现了暴露的风险。所以这种场景下，BeyondCorps的SDP模式就能帮助企业隐藏敏感服务，提供细粒度的访问控制。虽说这不是云平台原生提供的安全能力，但SDP借助云平台的开放接口，可以容易得对接到各大公有云。相比而言，如果在传统企业内网部署类似的SDP服务，则需要对传统网络结构、服务器应用进行大力度改造，几乎是不可能实施的（所以现在传统企业采用SDP主要是代替传统VPN，实现细粒度的访问控制）。

而在内部的网络中，同样也可以通过零信任的访问控制机制防止攻击者横向移动。

如在Openstack系统中，同一个主机内部的虚拟机是通过vlan进行隔离，不同租户的虚拟机是隔离的，内部网络访问通过安全组（SecurityGroup）可实现白名单机制，所以这种场景下，确实能实现零信任的防护。

在Kubernetes中，内部容器间访问控制和隔离可使用网络策略（NetworkPolicy）实现，需要注意的是业务网络通常取决于CNI插件，所以网络控制也依赖于CNI的实现。如果没有打开网络策略，默认情况下 Pod之间是互通的 ，所以要实现网络零信任，则需要将网络策略设置为白名单模式。如下面的策略是默认禁止所有进出流量：

apiVersion:networking.k8s.io/v1

kind:NetworkPolicy

metadata:

name:default-deny

spec:

podSelector:{}

policyTypes:

-Ingress

-Egress

可见，云计算系统的数据平面的可编程和软件化能力确实能够提供零信任的认证授权、资源隔离、访问控制的机制。

云原生应用的零信任

上一节主要谈的是IaaS和PaaS平台的零信任，在SaaS场景中，随着敏捷开发、高效运营的驱动下，用户越来越多地使用服务网格（Service Mesh）等云原生的架构开发应用。这些应用所在的基础设施虽然还在活跃开发中，但因现代化、软件化的基础设施使能、来自互联网攻击的防护需求，零信任理念已经随之落地。

云原生场景中，应用的颗粒度会被切得非常细，一个容器通常只运行一个或少数若干进程，故服务称之为微服务。所以，通常实现一个业务需要多个微服务的交互，所以在云原生场景中，服务之间的访问关系非常复杂，不能依靠实现固化的访问控制逻辑，而是应该按照业务的逻辑确定微服务间安全策略，划分微服务的边界进行持续有效的隔离，以及对微服务之间一致的访问权限控制，就变得非常重要。为了解决这个问题，云原生的系统通常都会有数据和管理平面的鉴权机制。

而在服务网格场景下，零信任还应覆盖微服务间的交互，这部分需要使用面向云原生的服务零信任机制。比较典型的方案是Google的Istio，我们在以前的文章（Istio的安全机制防护）中已有分析，也可参见 官方文档 。从功能上看，Istio可为微服务无缝加入认证授权和加密通信的功能。其思想是通过策略控制器，使用Kubernetes的RBAC授权机制，对资源粒度细到单个服务的访问进行控制，从而所有的服务交互都是可信的。

Istio在控制平面上，由Citadel组件做认证，Pilot组件做授权；数据平面上，在源目的服务旁插入Sidecar容器，截获进出流量，在进行加解密的同时，也根据Pilot的策略进行访问控制。

图5 Istio的访问控制和数据平面

图6 Istio的工作流程和组件

从效果看，如果攻击者没有合法身份，是无法在数据平面横向移动。因为在网络层，设置了网络策略白名单后，网络层的非法访问被禁止；而在服务层，微服务Pod开放服务较少，且都引入了认证和业务层访问控制，攻击者也很难发起非授权的连接。

从数据平面分析，Istio和SDP都需要对网络做比较大的修改。如SDP需要添加IH和AH，客户端需要添加组件，服务端也需要部署代理，而Istio的Sidecar容器也需要部署在所有业务容器旁，且截获流量，通过重写IPTABLES NAT表的方式将处理完的流量送回业务容器。

从结果观察，SDP在传统企业网络中部署因为上述原因遇到了非常大的挑战，但可预计Sidecar的部署模式会在服务网格环境中会成为主流的安全防护技术路线。原因是Sidecar虽然是一种侵入性部署模式，但全程自动化、用户友好：Istio主动监听Kubernetes-api服务获得新服务部署事件，通过仓库自动部署Sidecar容器，通过Init容器劫持流量，最后Sidecar使用Citadel和RBAC策略进行认证授权。一方面，业务方对安全机制毫无感知，所有开发、测试和运维均保持不变；另一方面，应用间能实现完备的认证和授权，最终达到内生安全。

零信任原生安全

从实践来看，云原生安全和零信任安全是有一定相关性的：

云原生的信任机制都是零信任的，云计算的开放环境，云服务的开放接口，必然要求云原生的安全首先要做好信任管理，全局、业务一致的白名单机制就是零信任的。而且在软件定义的基础设施下，在云原生环境下实践零信任机制是相对容易，无论是OpenStack Keystone的SSO的模式，还是侵入式的Sidecar模式，都可做到兼容业务，扩展功能，也贯彻了零信任的理念。

成功零信任机制必然是超越云原生的，虽然云原生应用越来越流行，但说到底这还是一个新兴领域，在大多数传统环境中还不能直接使用云原生中的零信任机制，这也是当前国内零信任只在少数大型机构试点的原因。但需要看到随着国外基础设施云化、企业网SDWAN化场景越来越现实，因而以固定网段、身份做隔离和访问控制的传统信任模型被打破，要求不区分地区、终端、时间能访问业务的需求越来越旺盛，所以零信任才被如此推崇。

看到这一点，我们就能得出一个推论：云原生的（零）信任机制，必然会扩展、连接到更多环境，如企业内网、移动网络，甚至物联网、工业互联网等，就如现在公有云开始连接企业内网、工业互联网连接生产环境和云平台的趋势一样。

那么，云原生的零信任机制，就需要借助其先进的软件能力和先进架构，开始适配云原生以外的更多应用场景，最终实现面向融合环境的零信任机制。

另外，零信任虽然给我们一种全新的信任管理理念，但不代表实现了“零信任”的机制就是万无一失、无懈可击的。最极端的场景下，如果访问主体本身怀有恶意的意图，虽然身份和权限是正常的，但其行为本身是异常的，所以“零信任是银弹吗”的答案显然是否定的。

零信任的最大价值在于减少暴露面和攻击面，所以应该在Gartner的自适应安全体系的预防（Prevention）阶段，还是应该假定存在攻击者侵入的可能性。正如NIST的零信任模型（NIST.SP800-207-Draft）[7]中包含了持续诊断和缓解系统，进行实时监测和及时响应。

所以，如何将零信任作为指导思想，融入到整个安全体系中，就需要我们设计一种零信任原生的形式化模型和安全架构。首先，应按照第一章中的信任模型定义主体、策略和资源，并根据现有安全资源的能力，动态地将策略下发到相应的安全设备、平台或强制点（enforcer），实现全局按需、动态、完备的策略控制。这方面可参见Firemon的访问控制管理[8]，不过它目前只包含对防火墙的控制，还不支持其他安全或网络设备。此外，检测后需要做自动化的响应处置，此时应能根据网络、安全资源和被攻击资源的环境动态下发控制策略，这可以借鉴绿盟科技提出的软件定义安全的体系（ 2015 、 2016 ）。

综上，“零信任原生安全”从设计上就体现了零信任理念，融合了多种安全能力；在实现上可适配各类应用场景的安全体系。它脱胎于零信任的理念，融合自适应安全的安全体系，有机形成预防、检测和响应的能力，利用云原生安全的架构和能力，通过软件定义的架构，可适配多种应用场景。

原文链接： https://mp.weixin.qq.com/s/hOcMlzQJ4jPlROc4Rvvk5Q