一、什么是好的安全体系
一个好的安全体系的前提是为合法主体建立信任关系，通过信任在保证业务的前提下降低安全成本，在运行时及时检测并消除非法主体的恶意行为，所以信任是网络安全的前提要求。
二、什么是信任
维基百科上对信任（Trust）的定义为：
一方（信任方）在未来依赖另一方（被信任方）行动的意愿。
假设给定三方A、B、C，三者之间都有交互，如下图所示。
那么信任是指主体A对主体B未来发生行为action(B)的依赖意愿，这里有两层含义：
信任是对主体B是否会做出行为action(B)的判断，包含了对主体本身B及其行为action(B)的双重判断。其中主体A对主体B的判断为信誉，记为Reputation(A,B)。
信任是用于判断主体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）、访问控制、边界控制等，具体产品就更是五花八门。但核心上看，信任管理有四个要素（如上图所示）：
主体身份属性确认，即Identification。
资源的属性确认，即Attribute Enumeration。
主体对资源操作的授权，即Authorization。
操作控制，即Enforcement。
行业内主流的信任管理机制都是采用了确定性的信任评估方式，设置后长期不变、控制面和数据面混合在一起，虽然简化了策略制定、系统运行时机制，但没有考虑到上下文变化，这是造成现在网络安全事件频发的根本原因之一。
从主体身份的角度看，主体身份是可能被假冒的，或合法主体在某些条件下会作恶。更具体可参考密码验证登录系统的操作，虽然系统安全策略要求用户设置复杂的密码，并要求定期更新，也不能完全假定用户是可信的。攻击者可以使用钓鱼、拖库等常见的攻击手段，获得用户密码。此外，虽然用户更新的密码复杂，但为了便于记忆，每次使用的密码存在规律性，也容易被破解。所以，现在越来越多的IAM方案采用无密码（Passwordless）、多因子认证MFA、生物技术Biotech等方式。
从资产属性的角度看，防火墙策略中五元组的目的地址所指示的就是被访问资源，但随着业务变更等环境变化，资源的属性也会随之变化，但如果安全策略没有及时更新，还是以之前的网络地址作为五元组的目的地址，显然会出现访问控制失效。事实上，在很多缺乏有效安全运营的大机构，这种现象是非常常见的。现在在一些以风险为基础的模型中，如Gartner的自适应访问控制，安全策略需要根据主体行为等上下文动态调整，这也体现了信任是主观、动态、不确定的。
从策略控制点的角度看，如云中的访问控制，随着虚拟机迁移，主体和资源属性、安全策略都没有发生变化，但资源所在的宿主机变化了，如果还在原宿主机的虚拟网络上执行策略控制，显然无法控制主体的访问行为。又如云中虚拟子网内部的流量不会经过虚拟路由器或虚拟防火墙，如果将这些虚拟设备作为子网内部访问行为的策略控制点，也是不合适的。可见，访问控制点应根据主体和资源间的访问路径进行动态部署，且其数据平面的处置应与控制平面的安全策略一致。
从控制面和数据面分离的角度看，传统的OSI TCP7层协议存在原生地安全问题，鉴权/授权的通道和数据传输的通道是混合在一起的（ip直连），这间接导致了网络缓冲区溢出、暴力破解、内网横向渗透等问题。
所以，一个好的信任管理机制，在控制平面需要保证主体、资源属性与安全策略在运行过程中保持一致；在数据平面，操作控制点能时刻在主体和资源的访问路径上；同时还要注意控制面和数据面要保持合理的独立隔离。
目前为止我们分析了信任管理，那么“零信任”又是什么呢？我们不禁要问，世界上到底有没有零信任？
答案是：“没有”，也“有”。
首先，从人性的角度看，世界上“没有”零信任。信任亘古以来就是一切人类重要活动的前提，论语有云：人无信不立，业无信不兴，国无信则衰。我们经常看到，当一个机构的安全管理者认为业务存在风险时，动辄限制合法用户的访问权限，或将业务功能降级，以期满足风险合规的要求。但这种做法没有区分合法用户和恶意攻击者，一概认为用户是不可信的，从结果上看约束了业务的正常开展，降低了企业各项业务的收益。
其次，从技术的角度看，世界上是“有”零信任的。至少到现在为止，我们看到区块链及其之上的应用可以是零信任的。正因为区块链有去中心化的共识机制，能让上层的智能合约全局一致地执行，从而支撑了事前无信任或弱信任的多方进行复杂交易。可以说，共识算法是公有链零信任的基础，但这样的零信任基本是建立在机器与机器之间的关系，显然不是当前业界在谈的“零信任”。以人为本的业务的信任机制还应是基于传统的信任模型。
从上面的分析可见，“零信任”从字面上看是有误导性的，世界上不存在完全不信任任何主体的业务，所谓“零信任”安全，更准确的说法应该是“默认不信任，时时处处验证”安全。
三、零信任的技术路线
到底什么事您想要的“零信任”，各位甲方朋友PPT看了无数版，各方的售前汇报听了好多场，方案过了N版，交付难得头疼也经历了。要想做好这件事，我们需要去对这个底层技术有个了解，反过头再去看我们的“零信访”是不是花拳绣腿，是不是忽悠其中。
从技术上看，要做到信任管理，或在身份上下功夫，或在控制上下功夫。现有业界的零信任方案必定落到某个具体的技术领域内，如
身份和权限管理
网络访问控制
区域隔离
应用安全等
需要注意的是，以上技术路线之间只是一种概念和侧重点上的划分，在实际的技术方案和产品中，往往是融合多种不同的技术路线。
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）根据指令放行或阻断。
BeyondCorps的路线最早见Google BeyondCorps项目，其流程见下图，认证请求是由用户访问的服务发起的，控制点也在服务侧，所以该服务的角色就是代理。
从效果看，这两种技术路线都是隐藏后面的应用，除非用户提供了自己的身份和访问资源，否则用户是无法访问应用的。从部署上看，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策略进行认证授权。一方面，业务方对安全机制毫无感知，所有开发、测试和运维均保持不变；另一方面，应用间能实现完备的认证和授权，最终达到内生安全。
