本文约1万字，仅作为我们零信任网络建设实践过程中的一些经验的记录，抛砖引玉，后续也将有更多的建设细节呈现出来，希望同大家分享，并共同探讨零信任网络建设方法，共同解决建设过程中遇到的困难。

01 零信任初识

困境

传统的IT组网中，网络安全需求的落地往往把重心放在以下工作：

1. 精心设计的网络结构，如：带外管理网段/带内生产网段的严格划分、不同网段之间的严格隔离等；

2. 在网络边界部署专用安全“盒子”设备上，如：F5、IPS、WAF、DDOS等。

这些经典的网络安全部署方案，长期以来起到了较好的安全防护作用。但随着企业网络规模的日益扩大、网络攻击技术的不断发展、云技术/容器化的不断发展，传统安全方案的缺点越来越明显。

1. 整体防御能力重边界、轻纵深，面对攻击者的横向扩展束手无策

复杂的网络部署环境造成过长的网络边界，单点突破往往难以100%杜绝，“容忍单点突破、杜绝全面失守”已成为系统化安全建设的共识。而在过于强调边界防护的传统安全方案下，网络边界越来越容易成为实际上的“马奇诺防线”。

攻击者往往第一步会通过应用薄弱点（0day或nday）、水坑攻击、钓鱼邮件等手段绕过企业重兵部署的防御边界，找到突破点后，通过端口扫描探测更大的攻击目标。

2. 检测能力的局限性

WAF、IPS、DDOS等安全防护设备，都是基于规则进行防护。攻击者常用以下两种方式来实现对防护的逃逸：

1）通过编码、异形报文进行逃逸；

2）通过大流量的攻击报文，超出设备检测能力逃逸。

3、审计、权限控制的缺失

当攻击者或内部人员以正常业务操作途径，尝试恶意登录、越权下载数据、破坏数据完整性时，现有的“盒子”设备欠缺防护能力。对于上述恶意操作，一般以以下方式进行管控：

1）确保业务系统对人员的最小授权；

2）能够通过审计能力，在事中或事后发现侵害行为；

3）通过动态风控手段，结合一定规则、用户行为特征，实现侵害行为的事前阻断。

4、无法满足企业服务上云后的安全需求

服务上云已经成为越来越多企业的必然选择，公有云、混合云部署场景下，云上服务存在网络界面扁平、攻击面大、服务动态伸缩等特点，传统的防护手段已无法适用。而现有云上的安全组、防火墙策略，则存在配置不灵活等问题。

零信任

应对传统企业防护方式的困境，零信任的思想及网络架构的出现，给我们提供了另外一种防御的思路。在过去的10年里，零信任的演进也让我们看到了问题解决的更多可能性。

2010年时任Forrester研究机构的首席分析师John Kindervag提出了零信任（Zero Trust）的概念。

2017年Google对外宣布基于零信任概念的新一代网络安全架构BeyondCrop落地完成，外界普遍认为此次Google网络安全架构的改革，与Google在“极光行动”中总结的经验教训有关。

2019年9月，NIST发布了Draft NIST Special Publication 800-207《Zero Trust Architecture》为给出了零信任官方意义上的解读。

2020年2月NIST对其进行了更新，发布了Draft (2nd) NIST Special Publication 800-207，细化了零信任架构的细节，更有力的推动了零信任思想的发展和落地。

零信任思想，引用NIST Special Publication 800-207中的一段话：

“Zero Trust Architecture (ZTA) provides a collection of concepts, ideas, and component relationships (architectures) designed to eliminate the uncertainty in enforcing accurate access decisions in information systems and services. ”

本质上讲，“零信任”是一种思想，并不是一种“技术”，同时，也很难有一款产品，可以称之为“零信任产品”。但从另外一个角度思考，凡是符合零信任思想的安全产品甚至是网络产品，也都可以称之为“零信任”产品。

零信任架构，就是利用“零信任”这个思想，所建立起来的企业网络安全架构。

根据NIST白皮书中的声明，零信任架构应该遵循6项基本原则

1. All data sources and computing services are considered resources.

所有的数据源及计算服务，均被认为是“资源”。

2. All communication is secure regardless of network location.

不论处于什么网络位置，所有的通信都应以安全的方式进行。

3. Access to individual enterprise resources is granted on a per-connection basis.

对于企业资源的访问权限授予，应基于每个链接。

4. Access to resources is determined by policy, including the observable state of user identity and the requesting system, and may include other behavioral attributes.

对“资源”的访问授权，应取决于策略，包括了用户的身份认证和发起请求系统的持续可观测状态，可能还包括了其他的行为属性。

5. The enterprise ensures all owned and associated systems are in the most secure state possible and monitors systems to ensure that they remain in the most secure state possible.

企业应确保其所拥有或与之相关联的系统处于尽可能的安全状态，并通过对其的持续监控确保它们总是尽可能的处于安全的状态。

6. User authentication is dynamic and strictly enforced before access is allowed.

用户在访问授权之前，必须进行强制的、动态的身份认证。

为什么是零信任

企业采用了零信任的思想来搭建企业安全架构，因此应遵循下列假设

1. The enterprise private network is not trustworthy.

企业内部网络是不可信的

2. Devices on the network may not be owned or configurable by the enterprise.

网络上的设备，可能不是企业所有的设备，或者无法由企业无法进行配置

3. No device is inherently trusted.

没有设备是天然被信任的

上述的3条假设，本质上完全推翻了传统企业防护的思路：在边界架设防护措施，并且无条件信任区域内部的流量

当企业内部网络不可信后，每一条请求都需要正确的权限才能够到达目标资源，使得横向扩散变得更加困难

建立企业设备信息库，防止攻击者通过窃取密码或者令牌获取访问权限

引入设备信任评估，防止员工电脑因钓鱼、水坑等攻击手段致使设备被攻击者控制，进而威胁企业网络安全

进而，我们将零信任对企业资产&数据资产的防护方式进行了归纳：已知的用户，在安全可信的设备上，使用加密链路，通过预置的授权访问到对应的资源。同时，采用零信任架构构建的企业安全架构，也可以不再关心服务部署方式与企业网络结构。

02 零信任全景

自我们的建设的过程中，总结出我们心目中相对完整的零信任网络结构，大致如下图， 

在数据平面层，我们需要通过网关（包括4层协议网关与7层协议网关），来实现数据的收口，以便实现权限的控制。

更为安全或复杂的场景，可以辅以安全客户端，来保证数据来源环境信息的可靠性。

在管理平面层，零信任的核心思想在于认证、授权以及持续的信任评估，因此，对应的需要“单点登录”来实现访问源的身份认证，需要IAM（Identity & Access Management

）来实现权限管理，需要“风控中心”来进行持续的风险评估，通过“决策中心”将上述三部分进行串联，实现一次访问请求的权限授予。

当安全客户端存在时，则对应的需要其管理的服务端。服务端实现了客户端的管理与信息的收集，并以此整理“设备信息库”。客户端的管理与可控，则是以PKI为基础来实现的。

基于上述各组件，列举出其所包含的功能点，如下所列 

因此处只列举了如“安全客户端”、“安全网关”、“决策中心”、“管理平台”等组件的功能点，而类似于SSO，PKI等，由于技术相对成熟，因此不再罗列。

关于各个组件功能点的详细描述，也会在后文中逐渐展开。

03 零信任建设思路

参照零信任思想（对每一条流量进行认证、授权以及持续的信任评估）建设的企业网络，基本上可以简化成下图 

基于上图，我们得到了零信任最简化的实现方式--“访问授信”，同时配以“安全审计”所达成的动态风控。此时只要在流量收口处（网关）执行决策中心所作出的放过/拦截的决策，则可以达成最初步的零信任框架。

采用上述框架，可以实现对Layer7流量的基本控制。选择7层流量作为零信任网络建设的入手处，原因在于：

1. 企业中，普遍存在7层网关，即企业的反向代理集群，流量收口工作已经初步实现
2. 7层协议开放度较高，如HTTP，通过cookie的支持，可以自由携带认证授权相关信息，实现起来相对简单。

因此，在建设最初的零信任框架时，我们需要完成下列组件的建设：

由于零信任网络处于建设初期，最可靠的实践场所是公司的办公网，即内网。

而在具体的办公场景中，也存在着大量无法通过7层网关实现管控的场景，因此，需要，因此数据平面的整体的网络结构也大致扩充如下： 

在引入Layer4层的网关之后，需要迫切考虑到的一个问题就是，4层流量并不像7层流量一样具有可扩展性，身份标识无法通过或者说很难通过4层流量携带并传递至网关。因此，方案就变成了，在用户原始报文之外，封装一层，将用户身份凭证封装在内。

引入了原始流量封装的需求，我们就不得不引入另外一个零信任中颇为重要的角色：安全客户端。

安全客户端与4层流量网关之间通过合理的身份认证与密钥协商，建立起可信的传输隧道，之后将用户身份认证凭证与原始数据包封装后通过可信传输隧道发送至4层流量网关，而4层流量网关在获取用户身份凭证后，根据授权结果，判定是否将原始用户流量向后端转发。

在流量封装与可信传输通道建立之外，安全客户端的另外一个作用，则可以对访问方所处的环境，进行客观可信的评估。如安全补丁的安装状况、安全配置是否合规等，这些重要信息，将作为决策中心评估是否可以进行权限授予的重要依据。

在此时，我们在零信任网络的建设中，将增加如下组件：

当企业具备了安全客户端的能力时，零信任网络则可以在它的安全属性之外，展现它的附加价值—提效，网络无边界。

何为“零信任”，即对一切区域、一切请求，均保持不信任的状态，需要对其进行身份认证、合理授权以及持续的信任评估。而此处提到的“一切区域”，自然也包括企业“内网”。因而，当零信任不在区别对待“内网”、“公网”时，通过零信任网络建设使得企业业务访问安全得到一定程度的保证后，其访问即可以不受“内网”限制。

由此，数据平面的网络结构，也可以大致演化为下图： 

相对于4层流量的管控而言，7层流量的管控，可以更细粒度一些，甚至可以做成API网关，而4层流量的管控，只能做到五元组级别。因此，相对来讲，L7的OA系统，更容易做到“网络无边界”。

但从另外一个角度思考，“内网”客观上，也作为一个环境存在，确实将提高攻击者攻击成本，因而，对于敏感业务的访问，将其保留在“内网”仍不失为一个好的选择。

在解决了办公场景下的大部分问题后，下一步我们将面临的问题是，分布在办公区、生产网等各处的“哑终端”入网安全性问题。

近些年，各方报告均显示，IoT安全问题日趋严重，RCE漏洞使其成为僵尸网络的重灾区。因其扮演的网络角色相对容易被忽视，而产品安全的能力又良莠不齐，很容易成为攻击者的突破口，进而造成更严重的网络安全事故。

最简单的限制方式，是对哑终端的IP进行限制，使其能够访问资源最小化。当哑终端因IP变化或其他更复杂原因，则需要考虑引入证书对其设备与流量进行认证，相对而言，这部分的建设成本会比较高，但如果企业有私有的PKI系统的话，将会节省很大一部分建设成本。

总结上述信息，我们得出了一个零信任建设需求的优先级列表，供参考：

实现企业网络的基本隔离，至少应该达成区域间的隔离

构建零信任管理平台，包括策略配置管理（或引入IAM），构建策略模型，建立基本的访问准入准则

构建零信任决策中心，包括身份认证（SSO）、策略查询（IAM）与授权、风险评估等

依托于企业7层流量代理网关，联动决策中心，实现对企业7层业务流量的基本管控

实现安全客户端，此步骤中，至少应实现认证与可信隧道能力，以此达成与4层网关联动的能力。客户端信息与环境检查，如安全性检查、病毒查杀等能力，则可以考虑通过采购的方式补足

4层流量网关的搭建，联动决策中心，与零信任客户端一同实现4层流量的认证与授权

建立企业的PKI/CA系统，以此来保障客户端可信与加密隧道安全

建立完善的风险识别体系，使零信任网络具备持续信任评估能力，在必要时刻，持续信任评估能力可以缩短MTTD与MTTR

哑终端管控能力覆盖

下文会根据所列需求，展开讲述各组件的建设细节。

04 零信任管理平台

在构建零信任策略配置管理平台之前，先需要确定策略模型与管理方式

我们在策略模型的建立上，采用了语言中“主语”+“谓语”+“宾语”+“修饰语”的方式，引入了4个单位：Subject、Action、Resource、Environment，因此简称之为SARE模型

S-Subject 授权主体

A-Action 授权可执行动作

R-Resource               授权可访问资源

E-Environment        满足授权条件/环境

授权原则：SCAN DO AON RIF E

主体对象（认证）：可以包括用户/组，IP，设备，服务等

资源对象：服务，API等。此处设计，为保证兼容4/7层流量授权

执行动作：接入，Method，CMD等。同样，为兼容4/7层流量授权

条件环境：网段，时间，地理位置，设备信息/健康状态等，条件信息可多样化，可定制

如下图中实例： 

根据图中信息，得到策略描述：LiLei、HanMeimei以及三年二班全体同学，都可以在每天的早7点到晚18点之间，在学校计算机室中（计算机室网段10.10.0.0/16）中，访问http://r.zerotrust.com/student_info，但仅限于通过Get请求或Post请求。

在管理方式上，则引入Realm概念，用以标识唯一管理单元。自我们的建设经验来看，该单元可以包括域名以及IP。

在Realm之下，我们使用Service来标识该管理单元下服务。一个域名或IP下，可以通过不同的端口，对外开放出不同的服务，如HTTP服务、SSH服务等。但在此处注意的是，端口（Port）的重要性，要高于服务协议（Protocol），因为端口决定了流量的走向。

策略Policy则归属于各个Service，且每个Service中可以存在多条Policy，Policy之间相对独立，但存在先后顺序关系。

策略中会包含我们上述所说的SARE模型，同样的，我们也允许每条策略中包含多个Subject、Resource以及Environment。

最后，为了方便管理，我们引入了Realms的概念，类似于文件夹的使用方式，用以对Realm进行归类，方便查看管理。但此概念非必须。

最终，我们形成的管理方式如下图：

05 零信任决策中心

零信任决策中心的建设，分为“认证”、“授权”以及“风险评估”部分的建设。

关于认证，我们在建立策略模型的时候提到过，认证的主体，包括但不限于“用户”、“服务”、“设备”甚至“IP”等。

• 对用户认证的场景

在聊及用户认证时，我们常会想到1993年，漫画家 Peter Steiner的一幅画：On the Internet, nobody knows you're a dog 

因此，单纯的账号认证，没有任何意义，因为账号（凭证）≠身份。当该账号背后有确切对应的身份，且可以确定当前账号的使用者可以与之关联时，认证才有意义。

在建设零信任决策中心的认证部分是，我们强烈建议其与企业现有的SSO系统相结合，原因如下：

1. 可以复用当前完善的账号体系
2. 可以复用SSO已经实现了的多因子认证能力，甚至借其实现梯度认证能力
3. 可以复用SSO提供的登录态，当业务也接入SSO的时候，避免因此而产生的多次登录

• 对服务认证的场景

对服务认证的场景，普遍存在于生产网络内部，服务与服务之间的调用与信息互换。此处有两种实现方式：

1. 原始流量中携带服务签名，由此可得服务唯一ID，在网关或服务侧以此为依据进行服务认证
2. 使用“客户端”方式，对服务进行可信代理，封装认证凭证，通过4层流量网关实现认证

如果企业当前的基础架构已经实现容器化，则基于容器化的隔离与认证方案将更有利于服务间的认证与授权。

• 对设备认证的场景

例如打印机入网、可视化大屏入网以及其他哑终端类设备入网。此类认证方式，可结合Radius实现，也可以通过设备证书方式实现。前者实现起来更加快捷，适用性也较强，后者安全性更高，但相对实现成本也很高。

• 对IP认证的场景

对IP而言，不应称之为“认证”，因为不存在任何认证过程，也不存在可信身份。但此场景最终被实现的原因是，我们终归有一些或暂时、或永久不能解决的场景，无法对明确的主体进行授权，而为保证这部分流量或业务不会因为零信任网络建设而受到影响，我们对之进行了妥协。

但无论如何，对IP授权不应广泛的被使用，因为IP授权无法得到有效的权限收敛，也很难进行风险持续评估与审计。

关于授权，我们试图用两条“链”来阐述我们所实现的授权过程

• 策略链

假设场景如下：访问主体LiLei，为三年级一班的同学，自寝室IP 10.33.27.135访问http://r.zerotrust.com/english获取学习材料（此处假设Environment都满足的情况下，关于Environment链，将单独描述。同时为了简化场景，此处Action也暂不予以考虑）

对HTTP Service r.zerotrust.com存在6条策略

LiLei同学此次访问的授权过程，可如下图所示：

策略链中，存在可以满足授权（不论Access或者Denied）的情况时，授权且退出链 

• 环境链

当引入环境条件时，授权将变得更复杂起来。但我们认为环境条件的存在时有必要的，通过环境条件的配置，可以实现授权条件的更细粒度约束，也让整个授权配置变得更加灵活。

假设一条访问策略中存在4个环境条件

可以看到，环境条件中，引入“属性”概念。属性被我们赋予Requisite或Sufficient，分别表示“必要不充分条件”及“充分不必要条件”。

4条环境策略所形成的环境链，可以表示成下图：

关于授权时的风险评估，虽然是零信任思想中较重要的一部分，但如果缺失这部分能力，网络也可以正常工作，是提高网络安全性锦上添花的功能组件。

授权时的风险评估，区别于“持续的信任评估”，是一项实时的工作，因此，可以评估的信息，均为静态的、实时的信息，如访问源设备操作系统版本、补丁安装情况、最近一次病毒查杀结果、是否安装DLP软件等。

此部分工作，很大程度上依赖于安全客户端的信息采集。

当风险评估结果显示，访问源安全性不足，此次授权结果将被更改，甚至直接被拒绝访问。但同时，应当给予用户充分的反馈以帮助用户改善环境安全，提升风险评估等级。

06 零信任L7网关

依托于企业成熟的代理网关（Nginx），可以实现L7网关的快速搭建。以当前企业中常用到的一种网络结构为例 

LVS（Linux Virtual Server）作为负载均衡器，将流量负载，而后实现SSL卸载、日志记录以及定制化需求配置（如HTTP至HTTPS跳转等）。

中间层代理服务器（Nginx）则作为WEB服务网关，将流量代理至真正上游应用中。在更精细化场景中，这一层也可以用作API网关，因此选型也相对多样化，如OpenResty、Tengine、Kong等。

我们所要实现的零信任7层流量网关，在此结构下，则可以与第二层代理服务器相结合。复用第二层代理服务器的优点如下：

1. 成熟且稳定的网络结构
2. 无需在网络中增加一层，降低链路中的损耗
3. 专业的SRE、网络、运维、故障处理团队守护

我们在这里，使用Lua完成了网关策略执行点（PEP）的快速开发。同时，插件的方式集成到代理服务器中，保证了开发与部署的独立性。

为了保证访问性能，降低网络损耗，在网关中我们使用了授权信息缓存的方式，即将个人认证信息以JWT形式存储至用户cookie中，将授权信息短时保存在网关的缓存中。这种方式一定程度上牺牲了安全性，但安全与性能之间，总需要保持一定的平衡，进行一定程度的取舍。

另外，在零信任思想中，所有网络传输均需要被加密，包括零信任网关至上游服务之间的通信。Google通过内部开发的高性能认证和加密框架LOAS（Low Overhead Authentication System，低开销认证系统）实现零信任网关至上游服务之间的双向认证和加密。但我们评估了开发成本与安全性，决定采用一种较为取巧的方式来保证上游服务器的安全，即通过防火墙策略保证上游服务只信任来自零信任网关的流量。

最后补充一个细节，不建议零信任网关拦截非授权原因造成的403返回码，也不建议零信任网关拦截非网关配置所造成的502返回码，因为这两部分返回码的拦截，将会给零信任网关的运维造成非常多的不必要工作量。

07 零信任安全客户端

零信任安全客户端的建设，一方面为了满足4层流量的身份凭证传输以及可信的隧道传输能力，另一方面，为了实现访问源环境信息的采集。

认证及隧道传输部分，我们建议在能力允许的范围内，尽量以研发的方式实现，因为这部分将与4层流量网关产生联动，而4层流量网关又需要与企业先前建设的管理平台及决策中心进行联动，因此定制化较强。

最基础的安全客户端应该具备以下能力：

身份认证：将身份信息提供至服务端，由服务端联动SSO或LDAP，完成身份认证。此处可引入多因子认证来保证认证身份的可靠性。身份认证后，客户端将保存服务端下发的身份凭证，并在请求流量中，携带身份凭证，以便网关根据身份完成合理授权。

流量代理：客户端通过创建虚拟网卡，代理指定网段流量（这里我们假定10.0.0.0/8网段），并将报文进行封装，以携带身份认证信息。 

加密隧道：通过与网关的协商/交换密钥，建立TLS1.2通信隧道，保证通道的安全性与可靠性。进而将虚拟网卡封装好的报文传输至网关侧。

客户端与网关及服务端联动时序如下图： 

在基础功能完备情况下，则需要考虑客户端实现信息收集及其他附加功能，如配置下发、病毒查杀等。最为简单快捷的方案，是通过商业产品采购，如DLP、UEM、杀软等进行能力补足。通过唯一设备标识，与商业产品形成联动，访问商业产品服务端接口，获取对应的客户端详细信息。

而不论以何种方式获取设备信息，至少应该包括：

设备的唯一标识

设备登记/初次入网时间

设备MAC与IP地址信息

设备硬件信息

设备操作系统类型及其精确的版本号

设备关键安全配置情况

设备最后一次可靠杀毒时间及结果

对应的，服务端在收集到这些信息后，应当以唯一标识为索引，建立起设备全生命周期状况跟踪，包括重要硬件替换等，直至设备被标识销毁。

08 零信任L4网关

零信任四层流量网关的建设，完全依赖于安全客户端的建设进度。没有4层流量网关的安全客户端，尚能完成用户环境信息收集，但没有安全客户端的网关，则无法完成任何工作。

零信任4层流量网关应具备能力如下：

流量还原：自TLS隧道中获取报文，将外层封装部分（Private DataLen与Private Data）摘除后，还原用户请求报文。

授权请求：自Private Data中获取用户身份凭证、设备唯一标识等信息，并以此向零信任决策中心请求此次访问授权结果

会话管理：依照授权中心判定结果，决定流量转发/拦截

相对于7层流量网关，可以与现有网络组件相结合，4层流量网关则需要完全从头搭建，因此需要综合考虑性能及吞吐量问题。合理计算并部署集群资源，正确的负载均衡实现，充分可靠的监控及报警设施都是保障服务稳定的必要措施。

另外，需要值得注意的是，4层流量网关目前不具有降级功能，降级意味着企业服务对外完全敞开。因此，当紧急事件发生时，需要考虑其替代方案，如VPN等。最坏情况，也需要保证“逃生门”可用。

09 零信任风险识别

零信任风险识别，旨在通过持续的信息收集及分析，完成信任的持续评估

而在开篇时曾经讲到，企业引入零信任思想及网络架构，以解决传统安全架构中无法解决的问题，但我们不否认传统安全手段在某些领域的有效性。因而，零信任网络的出现，并非替代传统安全设施，而是期待与传统安全措施相结合，以产生更为快捷、有效的防御机制。 

综合来看，我们建议使用与SIEM（安全信息和事件管理工具）相结合的方式来实现信息的收集与分析，最终达成信任持续评估的目的。

SIEM作为企业网络防御的核心部分，可以与零信任网络形成更为有效的闭环：

零信任网络向SIEM输入更为有价值的分析数据

SIEM作为事件分析与处置决策发起者

零信任网络作为最终事件处置执行点存在

下表列举了零信任与SIEM联动后，对于各类安全攻击的防御措施及处置方式。

除此之外，零信任平台中，需提供了人工风控入口，弥补自动识别缺陷，可实施登录态踢出、黑名单添加等动作，作为应急处置的手段存在。

10 其他零信任组件

相对于上述组件的建设，零信任关于网络隔离部分，各个企业的实施方式不同，因此本文不再深入介绍。

PKI/CA设施建设，本文中默认为企业基础设施建设，也不在赘述。

关于哑终端覆盖部分，我们也正在积极探索，但尚未完成相关部分的建设，因此待方案成熟后再进行补充。

11 结语

零信任网络建设，是一项艰难且长期的工作，建设过程中涉及许多同SRE团队、网络团队甚至业务团队协作完成的工作，但其可见的效果值得企业投入并持续迭代。

本文仅作为我们实践过程中的一些经验的记录，抛砖引玉，后续也将有更多的建设细节呈现出来，希望同大家分享，并共同探讨零信任网络建设方法，共同解决建设过程中遇到的困难。