技术分享｜零信任网络建设技术总结（下篇）

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

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

1）授权原则：S CAN DO A ON R IF E

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

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

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

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

如下图中实例：

根据图中信息，得到策略描述：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进行归类，方便查看管理，但此概念非必须。

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

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

关于认证，我们在建立策略模型的时候提到过，认证的主体，包括但不限于“用户”、“服务”、“设备”甚至“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授权无法得到有效的权限收敛，也很难进行风险持续评估与审计。

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

假设场景如下：访问主体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条环境策略所形成的环境链，可以表示成下图：

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

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

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

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

依托于企业成熟的代理网关（Nginx），可以实现L7网关的快速搭建。当前公司的网络结构为例：

LVS（Linux Virtual Server）作为负载均衡器，将流量负载至第一层代理服务器（Nginx）中。

第一层代理服务器（Nginx）实现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返回码，因为这两部分返回码的拦截，将会给零信任网关的运维造成非常多不必要的工作量。

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

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

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

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

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

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

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

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

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

• 设备的唯一标识

• 设备登记/初次入网时间

• 设备MAC与IP地址信息

• 设备硬件信息

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

• 设备关键安全配置情况（如是否配置密码、锁屏等）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相对于上述组件的建设，零信任关于网络隔离部分，在符合安全管理要求的情况下进行，因此本文不再深入介绍。

PKI/CA设施建设，归属于另外一个企业安全基础设施建设的领域，也不在此赘述。

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

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

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