零信任（二）NIST 架构与思考总结

本篇是干货满满的架构设计介绍。

零信任系列分为两篇：

历史 + BeyondCorp
NIST 架构 + 总结与思考

本篇是 NIST 架构 + 总结与思考

NIST 零信任架构

这是美国国家标准与技术研究院（NIST）出的一份零信任白皮书（见资料 1）。内容如下：

第一章开篇介绍零信任。介绍历史，回答了零信任的起源是什么
第二章定义了 ZT 和 ZTA，并列出了为企业建立零信任架构的要点，还包括了零信任设计原则的列表。回答了什么是零信任
第三章描述 ZTA 的逻辑组件或构成模块，以不同的方式组合 ZTA 组件是可行的，但其提供的是相同的逻辑功能。回答了零信任的有哪些组件构成以及它们的部署方案
第四章列出了 ZTA 一些可能的应用场景。这些 ZTA 应用场景让企业环境更安全，更不容易被入侵，包括远程员工、云服务和访客网络等。针对一些特定的场景，回答了零信任如何部署的问题
第五章讨论了 ZTA 环境下企业会面临的威胁。其中许多威胁是与传统的架构网络下的威胁相似，但可能需要不同的防御技术。回答了零信任存在哪些威胁以及如何解决/缓解这些威胁
第六章讨论 ZTA 原则如何适用和/或补充联邦机构现有的合规要求。这部分对我们用处不大
第七章讨论迁移到零信任的一些方案。回答了如何迁移到零信任架构的问题
后面的内容是附录。其中附录 B 是比较有价值的，对于零信任组件和解决方案的当前成熟度，进行了调查研究。回答了现阶段零信任存在哪些瓶颈以及问题。

由于白皮书的内容还是比较多的，所以我这里挑一些我认为是重点的来讲。

这篇文章还是拿办公网零信任来举例，如果有特殊情况的话会标识出来。

NIST 架构

这是 NIST 的零信任逻辑架构图，它展示了主要的组件与它们之间的交互关系：

Subject：主体，发起访问的来源，不一定是人，也可能是机器
PDP：策略判定点，包含 PE、PA
PE(Policy Engine)：策略引擎，负责决定是否授予主体对资源的访问权限，它的核心作用是做信任评估
PA(Policy Administrator)：策略管理器，负责控制主体与资源之间的连接，会按照 PE 的决策结果，向 PEP 发出允许或拒绝连接等指令，还为主体创建用于访问资源的身份令牌或凭据。PA 的核心作用是策略判定点，是零信任动态权限的判定组件
PEP(Policy Enforcement Point)：策略执行点，负责执行决定。看起来是单个组件，实际上也可以进一步分为两个不同位置的组件：客户端组件（如用户侧的 Agent）与资源组件（如资源侧的网关）
CDM：持续诊断与缓解系统，负责收集关于企业系统当前状态的信息，并对配置和软件组件，应用已有的更新；还负责向策略引擎提供关于发出访问请求的系统的信息，例如它的操作系统、应用程序是否打过补丁，或者系统中是否存在已知的漏洞
Control Plane：控制平面，零信任组件之间通信走的链路
Data Plane：数据平面，用户访问应用走的链路
PKI：公钥基础设施
ID Management：身份管理
SEIM System：安全信息与事件管理系统，收集以安全为核心、可用于后续分析的信息

到这里，我们就可以看懂用 NIST 术语来描述的零信任架构了。为什么要懂这个呢？因为后面根据不同的场景，会有不同的架构设计。但是看图我们很容易可以出一个结论：只有 PEP 的架构（位置、实现）会有不同，其他组件落地起来都是类似的。

从主体到企业资源这一条链路上，每一个点都可以部署 PEP。PEP 距离企业资源越近，PEP 防御面就越广，攻击者对企业资源的入侵成本也越高。

下面是结合 NIST 4 种抽象架构以及行业实践的经验总结得到的。

PEP 在主体中与资源前

这套方案是比较重的，基于 SDP 设计的方案。

此架构的 PEP 分为 2 部分：

前置 PEP：如果主体是员工，则此 PEP 在员工电脑上，比如可以和 EDR 结合在一起；如果主体是应用（如生产网零信任），则此 PEP 在应用系统中，比如可以以应用 SDK 或独立进程存在
后置 PEP：每个应用都有一个 PEP，这样应用仅与后置的 PEP 通信。这个 PEP 本质上充当资源的反向代理，PEP 负责连接到 PA，根据 PA 配置的通信进行拦截或者放行。

举例，一个用户通过笔记本电脑（已安装前置 PEP）连接到一个 HR 应用：

用户向 HR 系统发起访问
该访问请求由本地代理 Agent 接收，然后将请求发送给策略管理器(PA)
策略管理器(PA)将请求转发到策略引擎(PE)进行评估。如果允许，则 PA 通过控制平面，在设备代理(前置 PEP)和 HR 应用的后置 PEP 之间配置通信通道（如包括IP 地址/端口、会话密钥等等）
设备代理(前置 PEP)和 HR 应用的后置 PEP 成功连接（可能还是加密的），开始通信
当通信结束，或发生安全事件（如会话超时、无法重新认证）时被策略管理器 PA 断开，连接终止

PEP 在网关中

PEP 在网络中间链路的流量代理设备上，例如 Google 的 BeyondCorp 就是采用的此方式（有一个叫 Access Proxy 的组件）。这种 PEP 的实现依赖大量的研发工作，国内的互联网企业常选用 Nginx、流量网关等便于定制的系统作为代理网关，部分乙方厂商也基于硬件设备、防火墙等实现。

过程是非常直观的，就不多说了：

但是，由于设备信息的收集是零信任非常重要的一个数据依赖，而从请求中可以拿到的设备信息非常少。所以这个图看起来不需要在设备上安装 agent，实际上还是需要安装一些软件或者是做一些改造的。

PEP 非常靠近资源

该方式常见于云原生的 Sidecar 模式。其实本质上也是 PEP 在网关中的模式，但在部署形态、升级方面与 PEP 集成在网关中的方式有较大区别。

过程也是非常直观的：

PEP 在资源中

PEP 以 SDK 或字节码形式集成在应用中，常见于大型互联网自研的中间件系统，存在极少厂商将 PEP 集成到应用的系统内核中。

设备应用沙盒

还有基于设备应用沙盒的方案，简单地来说就是 PEP 只允许来自可信应用的访问，但是我感觉太理想化了，极难落地，这里就不多说了，感兴趣的橘友可以去看看白皮书。

方案对比

各方案主要差异性对比如下（排除设备应用沙盒方案）：

我个人认为，PEP 部署在网关中这种模式，平衡安全效果与成本来说是最合适的。那么两个比较明显的缺点是：

确保所有应用都接入 PEP：由于很多公司都有一个代理网关给应用接入（提供负载均衡等等统一功能），那么直接在这种代理网关上集成或者做旁路咨询的方式就可以解决应用需要全部接入 PEP 的问题。
缺少端上信息：可以考虑用安装统一的软件来采集，因为现在的公司都会要求在设备上强制安装公司的某个软件（这种覆盖率可以说是很接近 100%），所以只需要在这种软件上做改造就行了。当然会有一定的成本，但是投入产出比已经很高了

另外，按照主体和资源的不同，企业内服务主要有办公网边界访问、生产网服务间访问、VPN 下访问办公网服务、生产网内部数据类服务等主要场景。不同的场景，有不同的方案。结合企业自身的情况，这几种不同的方案可以进行组合，做成一套多种形态的融合架构。

思考

这里简单分享一些思考，希望起到抛砖引玉的作用。

去边界

这段时间我看了非常多的资料。有许多零信任的定义和讨论都强调去除以边界防御。但我认为边界是从物理/网络边界转变成了逻辑边界，并且更加贴近资源。所以消除边界其实只是消除物理/网络边界，完全没有边界的说法并不准确。并且，零信任的目的也并不是为了干掉边界，去掉网络边界是因为它已经没有用处了并且去掉之后还可以提升研发效能。

大多数实施零信任的公司还是混合着零信任架构和基于边界防御的架构。我觉得这一点并没有什么问题，毕竟身为打工人就需要考虑投入产出比，只要能解决实际问题就行了。

零信任的安全风险

ZTA 肯定是不能彻底解决所有安全问题的（没有银弹）。它可以大大增加利用成本，比如迫使攻击者从撒网式钓鱼变成了鱼叉式钓鱼。

ZTA 还是比较年轻的技术。NIST 的白皮书指出：“ZTA 生态系统还没有成熟到足以大范围应用的程度”。并且还有一些未知的问题，在我们实施完零信任之后，可以进一步去探索：面对 ZTA，攻击者会如何反击？会不会出现新的威胁类型？已经采用 ZTA 的企业中，成功的入侵是什么样的？面对 ZTA，业务流程如何变化？等等。

当然，由于稳定性对于 ZTA 来说非常非常重要，所以攻击者也有可能尝试做 DDoS。但是这一点对于大部分业务/防护来说都很重要，传统的 VPN 其实也有这个问题。

从这一点来看，零信任非常需要可灰度、可监控、可回滚的能力。最理想的情况是，每次策略变更都可以通过监控对比旧策略与新策略的决策区别，确定没问题之后，分批按照百分比进行灰度，线上一旦发现问题可以马上回滚。这可以给运营人员提供强大的安全感，在上一个新的策略时，可以非常有效地分析管控的影响程度，出了问题也有及时止血的措施。

最后，智能算法能否用在动态能力上呢？我的倾向是尽量别用，策略/现象不可解释的话，排查问题的时候会非常痛苦。

可持续运营

上面的架构中没有提到运营，但其实运营层面的问题是尤为重要的。

对于办公网零信任来说，首先直接面向员工。站在用户的角度来说，他们不关心什么是零信任项目，也不关心这个项目是怎么实现的，他们只关心自己为什么没法访问这个页面，如果要解决的话，需要做什么。

如果仅仅在拦截页面放一个简单的提示，那么零信任运营人员会收到大量员工的支持请求：询问为什么无法访问以及怎么解决。长期下去会造成很多问题：

零信任运营在答疑上疲于奔命；等待的人多，解决时间变长，就会阻碍员工的工作（影响研发效能）
员工过于依赖人工支持。后期在推广自助解决方案的时候（比如在拦截页面上写明原因与解决方式）会比较慢，因为对于他们来说已经习惯了直接找人工
员工认为只要没法访问一个页面（甚至包括外网页面），都认为是零信任的问题
员工由于体验不好，并不认可这个安全项目，可能会导致领导层的质疑与决策上的犹豫，毕竟零信任这种影响全公司的项目一定需要从上到下的支持
...

为了方便诊断和解决更复杂的访问问题，可以设计一个网站来帮助用户和支持团队。不只是用一串通用错误代码来告诉用户他们的访问被拒绝，而是解释为什么他们被拒绝以及如何解决这个问题。比如一个应用要求员工申请后才可访问，那么这个页面可以提供拦截原因：“此应用设置了访问权限，被拦截是因为你没有申请访问权限。请点击链接申请，主管审批通过之后就可以访问”，附上到权限申请平台的链接，这样用户看到拦截页面之后，就知道点击申请，通过之后就可以访问了。

除了直接面向员工，零信任也直接面向业务侧。那么不同业务可能会有不同的鉴权方式（包括那些外采的应用），如何让它们统一接入 SSO 和如何打通业务权限和零信任的权限也都是重难点。如果没有打通，那么用户在访问应用的时候，需要在访问零信任之前登录（判断是哪个用户）然后做鉴权（判断这个用户有没有权限访问这个应用，没有的话可能需要申请），通过之后还要登录应用（应用本身的登录逻辑），如果应用有权限划分的话，那么可能还需要申请应用自己的权限码来访问特定的页面/功能。

这一套下来，会被业务方和用户骂死的。

除了提到的这些，还会有很多其他问题，由于现状不同，各个公司在落地上会遇到不同的问题，这是没法抄作业的。建议橘友们结合自身的情况，落地时不仅要在技术层面上思考，在运营层面的问题上也要多加思考。

技术上的 “忒修斯之船” 悖论

注：如果只关注某个技术能解决什么实际的问题，那么你可能确实不关心定位和概念，建议跳过这部分

什么是 “忒修斯之船” 悖论？

忒修斯之船更换了 1 块木板，这艘船还能叫忒修斯之船吗？

忒修斯之船更换了 2 块木板，这艘船还能叫忒修斯之船吗？

直到忒修斯之船更换了所有的零件，这艘船还能叫忒修斯之船吗？

技术领域同样有这个问题。

新的技术总是层出不穷，如何理解这些新的技术？它们的定位什么？

零信任去掉一个小功能，还叫零信任，再增加掉一个小功能，还叫零信任...直到零信任慢慢变成一个防火墙，还叫零信任吗？

这个我称之为技术上的 “忒修斯之船” 悖论。

那么怎么解决这个问题呢？我认为，每个技术都可以把它分为两种能力，一种是核心能力，它是业界共识的特征。如果连这个都没有的话，并且也不打算往这个方向做，那么这个肯定是有问题的。额外能力是在实现核心能力的基础上，额外可以实现的能力。

比如说零信任可以实现部分防火墙的功能，同样防火墙也可以实现零信任的部分功能，但用于区别他们之间的就是核心能力。并且，如果用防火墙实现了零信任的核心能力要求，那么你把这套防火墙称为零信任项目也没有什么问题。

需要注意的是，这里说这么多，目的并不是为了纠结这个概念。而是在大方向上提供重要的指导意义：我们要以完善核心能力为主要目的，额外能力作为建设的补充，它属于锦上添花而不是雪中送炭。如果集中精力建设的是额外能力，那么可能需要结合一下要解决的实际问题，去判断一下我们到底需不需要零信任，你需要的可能是另外一种技术。