一个好的安全体系的前提是为合法主体建立信任关系，通过信任在保证业务的前提下降低安全成本，在运行时及时检测并消除非法主体的恶意行为，所以信任是网络安全的前提要求。

维基百科上对信任（Trust）的定义为：

一方（信任方）在未来依赖另一方（被信任方）行动的意愿。

假设给定三方A、B、C，三者之间都有交互，如下图所示。

那么信任是指主体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的历史行为的观察{action(B)}
• 第三方（如主体C）对其信誉评价Reputation(B,C)的综合评估

事实上，信任度的度量会更复杂一些，需要考虑到观察行为（即证据）的可靠度，以及信任度随着时间推移衰减等因素。

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

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

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

• 从主体身份的角度看，主体身份是可能被假冒的，或合法主体在某些条件下会作恶。更具体可参考密码验证登录系统的操作，虽然系统安全策略要求用户设置复杂的密码，并要求定期更新，也不能完全假定用户是可信的。攻击者可以使用钓鱼、拖库等常见的攻击手段，获得用户密码。此外，虽然用户更新的密码复杂，但为了便于记忆，每次使用的密码存在规律性，也容易被破解。所以，现在越来越多的IAM方案采用无密码（Passwordless）、多因子认证MFA、生物技术Biotech等方式。
• 从资产属性的角度看，防火墙策略中五元组的目的地址所指示的就是被访问资源，但随着业务变更等环境变化，资源的属性也会随之变化，但如果安全策略没有及时更新，还是以之前的网络地址作为五元组的目的地址，显然会出现访问控制失效。事实上，在很多缺乏有效安全运营的大机构，这种现象是非常常见的。现在在一些以风险为基础的模型中，如Gartner的自适应访问控制，安全策略需要根据主体行为等上下文动态调整，这也体现了信任是主观、动态、不确定的。
• 从策略控制点的角度看，如云中的访问控制，随着虚拟机迁移，主体和资源属性、安全策略都没有发生变化，但资源所在的宿主机变化了，如果还在原宿主机的虚拟网络上执行策略控制，显然无法控制主体的访问行为。又如云中虚拟子网内部的流量不会经过虚拟路由器或虚拟防火墙，如果将这些虚拟设备作为子网内部访问行为的策略控制点，也是不合适的。可见，访问控制点应根据主体和资源间的访问路径进行动态部署，且其数据平面的处置应与控制平面的安全策略一致。
• 从控制面和数据面分离的角度看，传统的OSI TCP7层协议存在原生地安全问题，鉴权/授权的通道和数据传输的通道是混合在一起的（ip直连），这间接导致了网络缓冲区溢出、暴力破解、内网横向渗透等问题。

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

目前为止我们分析了信任管理，那么“零信任”又是什么呢？我们不禁要问，世界上到底有没有零信任？

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

• 首先，从人性的角度看，世界上“没有”零信任。信任亘古以来就是一切人类重要活动的前提，论语有云：人无信不立，业无信不兴，国无信则衰。我们经常看到，当一个机构的安全管理者认为业务存在风险时，动辄限制合法用户的访问权限，或将业务功能降级，以期满足风险合规的要求。但这种做法没有区分合法用户和恶意攻击者，一概认为用户是不可信的，从结果上看约束了业务的正常开展，降低了企业各项业务的收益。
• 其次，从技术的角度看，世界上是“有”零信任的。至少到现在为止，我们看到区块链及其之上的应用可以是零信任的。正因为区块链有去中心化的共识机制，能让上层的智能合约全局一致地执行，从而支撑了事前无信任或弱信任的多方进行复杂交易。可以说，共识算法是公有链零信任的基础，但这样的零信任基本是建立在机器与机器之间的关系，显然不是当前业界在谈的“零信任”。以人为本的业务的信任机制还应是基于传统的信任模型。

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

从技术上看，要做到信任管理，或在身份上下功夫，或在控制上下功夫。现有业界的零信任方案必定落到某个具体的技术领域内，如

• 身份和权限管理
• 网络访问控制
• 区域隔离
• 应用安全等

需要注意的是，以上技术路线之间只是一种概念和侧重点上的划分，在实际的技术方案和产品中，往往是融合多种不同的技术路线。

0x1：身份和权限管理 技术路线

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

0x2：网络访问控制 技术路线

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

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

CSA SDP模型

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

基于代理的ZTNA路线

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

0x3：区域隔离 技术路线

从结果看，“零信任”与隔离有很大的相关度。一些云厂商借助微隔离技术，可天然按照不同粒度隔离业务，例如VMware在NSX产品中提出用微隔离减少攻击面。

0x4：应用安全 技术路线 

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

而在服务网格场景下，零信任还应覆盖微服务间的交互，这部分需要使用面向云原生的服务零信任机制。比较典型的方案是Google的Istio。从功能上看，Istio可为微服务无缝加入认证授权和加密通信的功能。其思想是通过策略控制器，使用Kubernetes的RBAC授权机制，对资源粒度细化到单个服务的访问控制，从而所有的服务交互都是可信的。

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

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

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

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

0x5：云化基础设施与零信任

本质上来说，云计算安全是催生零信任的最早行业推动力。

• 公有云市场占有率不断提升，企业的关键业务会越来越多地部署在公有云上，其暴露面和攻击面越来越大，如SDP等零信任的技术可以将一些企业内部业务部署到公有云上，这些业务对外并不暴露，攻击者无法从互联网上找到这些业务，但合法用户却可以通过客户端或代理经过验证后访问这些内部业务。
• 此外，随着SDWAN的火热发展，企业的分支机构通过uCPE进行互联，边界设备大大弱化，相反如Zscalar等SDWAN安全厂商在运营商网络中提供了各种云化的安全能力，企业员工可在任意地点、任意终端登录企业各地分支机构的服务。
• 此外，云中虚拟资源迁移、业务变更频繁能到秒级，安全策略能否跟随业务，业务间的隔离粒度能否达到最小，也是零信任的原生需求

云计算系统的最大特点是所有资源虚拟化和软件化、平台集中化。其中，如认证和访问控制机制是云计算系统原生提供的，如

• OpenStack提供了Keystone认证服务、安全组、防火墙即服务
• Kubernetes支持多种认证、授权机制和网络策略

所以这些云平台的控制平面和数据平面都是原生支持零信任的。 

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

• 在VPC环境中，虚拟机如果没有分配浮动IP，外部是无法访问VPC内虚拟机的
• 又如Kubernetes只是新建了Pod或Deployment，外部也是无法访问该Pod上的业务的

所以云计算资源暴露面默认是没有的，从而避免了绝大多数来自互联网上的威胁。

至于当OpenStack为虚拟机分配了浮动IP、Kubernetes为Pod分配了Ingress或NodePort服务后，这些云资源对外提供服务，用户可在外访问，就出现了暴露的风险。所以在这种场景下，BeyondCorps的SDP模式就能帮助企业隐藏敏感服务，提供细粒度的访问控制。虽说这不是云平台原生提供的安全能力，但SDP借助云平台的开放接口，可以容易地对接到各大公有云。相比而言，如果在传统企业内网部署类似的SDP服务，则需要对传统网络结构、服务器应用进行大力度改造，这几乎是不可能实施的（所以现在传统企业采用SDP主要是代替传统VPN，实现细粒度的访问控制）。

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

• 如在OpenStack系统中，同一个主机内部的虚拟机通过vlan进行隔离，不同租户的虚拟机是隔离的，内部网络访问通过安全组（Security Group）可实现白名单机制，所以这种场景下确实能实现零信任的防护。
• 在Kubernetes中，内部容器间访问控制和隔离可使用网络策略（Network Policy）实现，需要注意的是业务网络通常取决于CNI插件，所以网络控制也依赖于CNI的实现。如果没有打开网络策略，默认情况下Pod之间是互通的，所以要实现网络零信任，则需要将网络策略设置为白名单模式。

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

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

• 云原生的信任机制都是零信任的。云计算的开放环境、云服务的开放接口必然要求云原生的安全首先要做好信任管理，全局、业务一致的白名单机制就是零信任的。而且在软件定义的基础设施下，在云原生环境下实践零信任机制相对容易，无论是OpenStack Keystone的SSO模式，还是侵入式Sidecar模式，都可做到兼容业务、扩展功能，也贯彻了零信任的理念。
• 成功的零信任机制必然是超越云原生的。虽然云原生应用越来越流行，但说到底这还是一个新兴领域，在大多数传统环境中还不能直接使用云原生中的零信任机制，这也是当前国内零信任只在少数大型机构试点的原因。但需要看到随着国外基础设施云化、企业网SDWAN化场景越来越现实，以固定网段、身份做隔离和访问控制的传统信任模型将被打破，要求不区分地区、终端、时间访问业务的需求越来越旺盛，所以零信任才被如此推崇。

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

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

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

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

所以，如何将零信任作为指导思想，融入到整个安全体系中，就需要我们设计一种零信任原生的形式化模型和安全架构。

• 首先，应按照信任度模型定义主体、策略和资源，并根据现有安全资源的能力，动态地将策略下发到相应的安全设备、平台或强制点，实现全局按需、动态、完备的策略控制。这方面可参见Firemon的访问控制管理，不过它目前只包含对防火墙的控制，还不支持其他安全或网络设备。
• 此外，检测后需要做自动化的响应处置，此时应能根据网络、安全资源和被攻击资源的环境动态下发控制策略，这可以借鉴软件定义安全的体系。

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