【零信任安全架构】NIST SP 800-207 架构深度拆解：不只是 7 条原则

大部分关于零信任的中文文章引用 NIST SP 800-207 时只做一件事：复述 7 条基本原则，然后跳到厂商产品对比。NIST 文档真正有价值的部分——逻辑组件模型、信任算法、三种部署变体、以及写规范的人故意留给实现者的工程填空题——几乎没人讨论。

本文拆解 NIST SP 800-207 (Zero Trust Architecture, August 2020) 的完整架构，聚焦三个问题：谁做决策、基于什么信号、决策怎么执行。

前置阅读：本站 IAM 全景。

一、逻辑组件模型：PEP、PDP 和两个子组件

NIST SP 800-207 把零信任架构拆成几个逻辑组件。注意”逻辑”——它们不必是独立的进程或服务，可以合并部署，但必须概念上正交。

1.1 核心组件定义

flowchart LR
    Subject["主体<br/>(用户 / 设备 / 服务)"] -->|"1. 访问请求"| PEP["PEP<br/>策略执行点"]
    PEP -->|"2. 转发请求"| PA["PA<br/>策略管理器"]
    PA -->|"3. 查询决策"| PE["PE<br/>策略引擎"]
    PE -->|"4. 运行信任算法"| PE
    PE -->|"5. 返回决策"| PA
    PA -->|"6. 配置 PEP<br/>(签发令牌/创建通道/拒绝)"| PEP
    PEP -->|"7. 允许/拒绝"| Resource["企业资源"]
    
    PEP -.->|"控制平面<br/>(决策通信)"| PA
    PEP ===|"数据平面<br/>(应用流量)"| Resource

PEP（Policy Enforcement Point，策略执行点） 是流量进入企业资源的关卡。它位于不可信区域和可信区域（资源所在）之间的边界。PEP 的职责是：

• 拦截访问请求，向 PA 请求决策
• 根据 PA 的指令建立、监控或拆除主体与资源之间的通信通道
• 持续监控会话，当 PA 通知策略条件变化时终止连接

PEP 可以是网关设备、sidecar 代理、或者拆分部署——一部分在客户端（如设备 agent），一部分在资源侧（如反向代理）。

PDP（Policy Decision Point，策略决策点） 是决策制定者。NIST 把 PDP 拆成两个逻辑子组件：

PE（Policy Engine，策略引擎） 是”大脑”。它接收来自 PA 的决策请求，运行信任算法（Trust Algorithm），根据所有可用的输入源做出最终的 grant/deny/revoke 决策。

PA（Policy Administrator，策略管理器） 是”执行手”。它接收 PE 的决策，然后：

• 通过控制平面向 PEP 下发指令（建立连接或拒绝）
• 当访问被批准时，生成会话级别的凭据或令牌（如 OAuth2 token、临时证书）
• 当 PE 后续判定需要撤销时，通知 PEP 关闭会话

NIST 明确指出 PE 和 PA 是紧密耦合的——在很多实现中它们就是同一个服务。但逻辑分离的意义在于：PE 只负责”做决定”，PA 负责”让决定生效”，两者的输入和输出不同，失败模式也不同。

1.2 控制平面与数据平面的分离

NIST 架构中有一条关键设计：PDP（PE + PA）和 PEP 之间的通信必须在逻辑上与数据平面分离。下图展示了这个分离：

flowchart TD
    subgraph ControlPlane["控制平面"]
        PE["Policy Engine<br/>(信任算法)"]
        PA["Policy Administrator<br/>(通道管理)"]
    end
    
    subgraph DataPlane["数据平面"]
        direction LR
        Subject2["主体"] <-->|"加密应用数据"| Resource2["资源"]
    end
    
    PEP2["PEP"] -->|"决策查询"| PA
    PA -->|"配置指令"| PEP2
    PE -.->|"评估输入"| ICAM["身份与访问管理<br/>ICAM"]
    PE -.->|"评估输入"| CDM["持续诊断与缓解<br/>CDM"]
    PE -.->|"评估输入"| TI["威胁情报<br/>Threat Intelligence"]
    PE -.->|"评估输入"| SIEM["安全日志<br/>SIEM / 活动日志"]

控制平面处理的是元数据——身份、设备姿态、策略规则、威胁情报。数据平面处理的是应用数据——HTTP 请求、数据库查询、文件传输。分离的目的不是性能优化，而是防止数据平面流量绕过策略决策——如果决策流量和应用流量混在同一个通道中传输，攻击者一旦控制了数据通道，就能拦截或伪造决策。

二、信任算法：决策引擎的三种模型

信任算法（Trust Algorithm）是 NIST 文档中最重要的概念，但没有被充分定义。NIST 只描述了它的输入源和三种抽象模型，具体的计算方式留给实现者。

2.1 信任算法的输入源

NIST SP 800-207 Section 3.3.1 列出了信任算法的输入：

这些输入源的更新时间不一致——设备姿态可能每分钟变化，企业策略可能数月不变——这是信任算法实现中最容易被忽视的工程问题。当信任算法依赖的某个输入过期了，决策应该更保守（拒绝）还是更宽松（放行）？NIST 没有给答案。

2.2 三种信任算法模型

NIST 描述了三种信任算法的抽象模型：

（1）基于条件的（Criteria-Based）

访问在满足一组特定的阈值条件时授予。每个条件是一个二元判断：设备是否处于管理状态？MFA 是否完成？地理位置是否在允许的国家？这种方式实现简单，但容易产生”悬崖效应”——差一分就不满足，满足了就完全信任。Google BeyondCorp 的信任等级（Trust Tier）本质上就是一个 coarse-grained criteria-based 模型，分三级。

（2）基于分数的（Score-Based）

从所有输入源计算一个综合的信任分数——每个输入维度的信号被量化并加权，得出一个连续值。访问在分数超过配置的阈值时授予。分数的优势在于可以动态变化——一个会话开始时信任分数是 85（允许访问高敏感资源），10 分钟后设备姿态变化导致分数降到 55（降级为只允许访问公开资源）。基于分数的模型是”持续验证”的技术基础。

分数模型的工程难点： - 权重怎么定？ 设备不合规扣 30 分还是扣 50 分？权重没有科学方法，通常靠专家经验＋迭代校准。 - 分数改变的延迟：输入源更新的频率不一致——设备姿态每分钟更新、威胁情报每小时更新——分数是”最新的各维度加权和”还是”用旧数据补零”？ - 分数回退机制：一个信号源挂了（如威胁情报 API 超时），信任分数应该用”默认保守值”还是”忽略该维度”？

（3）单一 vs 上下文（Singular vs Contextual）

单一评估：每个请求独立评估。上下文评估：考虑实体的历史行为模式——同一个用户在过去 30 天内从未在凌晨 3 点登录，突然今天凌晨 3 点登录，即使其他信号正常，上下文评估也会标记为需要 step-up auth。

NIST 没有强制选择哪种模型，只是把它们作为参考架构描述出来。

三、三种部署变体

NIST SP 800-207 Section 3.4 描述了三种 ZTA 部署模型：

3.1 增强的身份治理（Enhanced Identity Governance）

这是 NIST 认为最常见的起点。核心思想：以身份（identity）作为控制平面。PDP 逻辑主要由 ICAM（Identity, Credential, and Access Management）组件承担，PEP 是资源前面的身份感知网关（如 Google IAP）。

flowchart LR
    User["用户 + 设备"] -->|"携带身份令牌"| Gateway["身份感知网关<br/>(PEP)"]
    Gateway -->|"验证令牌 + 查询策略"| IdP["ICAM 系统<br/>(承担 PDP 角色)"]
    IdP -->|"allow / deny"| Gateway
    Gateway -->|"允许的请求"| App["企业应用"]

适用场景：企业 Web 应用、SaaS 应用。局限：对非 HTTP 协议的支持有限。

3.2 微分段（Micro-Segmentation）

将网络划分为细粒度的安全区域，每个区域独立执行访问控制。PEP 可以是网络设备（交换机、路由器、防火墙）或主机上的 agent（如 Kubernetes NetworkPolicy 的实现、服务网格 sidecar）。这个模型在云原生环境中天然匹配——每个 Pod 可以是一个独立的安全区域。

NIST 指出微分段可以作为增强身份治理的补充，也可以独立部署。

3.3 软件定义边界（Software Defined Perimeter, SDP）

SDP 基于 Cloud Security Alliance (CSA) 的规范。其核心机制是：

1. 控制器（Controller）作为 PDP，维护哪些设备/用户可以访问哪些资源的策略
2. 网关（Gateway）作为 PEP，执行访问控制
3. 客户端和网关在通信前，必须通过控制器的身份验证和授权

SDP 的独特之处是”先验证后连接”（Authenticate First, Connect Second）——在没有通过身份和姿态验证之前，客户端甚至看不到网关的存在。这是通过 SPA（Single Packet Authorization，单包授权）实现的——控制器验证了敲门包后，才动态地在网关上为该客户端开放端口。

四、NIST 有意留白的工程决策

NIST SP 800-207 是一份”架构指南”而非”实施规范”——它的目标是让不同的组织和厂商都能在自己的环境中实现零信任，而不是规定一个所有人都必须遵守的协议。因此，NIST 留下了一组关键的工程问题没有回答：

4.1 PDP 的无状态 vs 有状态

PDP 应该为每个请求做一个独立的决策（无状态），还是维护会话状态（有状态）？无状态 PDP 水平扩展容易，但无法实现”持续评估——当会话中途设备姿态变化时撤销”。有状态 PDP 可以跟踪每个会话的信任分数变化，但需要存储状态并在 PE 实例间共享——这是一个 CAP 问题。

NIST 在 Section 3.3.2 中提到了”会话”的概念（“PDP 可以反悔之前的批准”），但不规定实现方式。

4.2 策略传播延迟

当一条策略变更了（如”从今天起，VPN 不再允许访问生产数据库”），这个变更传播到所有 PEP 需要多长时间？NIST 不提延迟目标。但在工程中，这决定了”紧急撤销”的时间窗口——如果策略传播延迟是 5 分钟，这 5 分钟就是攻击者的窗口。

4.3 身份系统单点问题

NIST 指出如果 ICAM 系统或 PDP 不可用，所有的访问请求都会失败（“fail closed”），因为零信任没有”绕过”机制。但 NIST 没有规定可用性目标。工程上，这意味着 PDP 必须是高可用（多副本 + 自动故障转移）——零信任架构把安全从”分布式边界”集中到了”PDP 高可用集群”，本质上是换了一种单点。

4.4 设备姿态数据库的一致性

设备数据库（CDM 系统的输出）是信任算法的关键输入。但设备状态是变化的——一台笔记本在上午 10:00 被标记为”不合规”（因为某个补丁没打），10:03 补丁打上了，CDM 数据库要多久才能更新这个状态？在这 3 分钟的窗口内，用户将因为”过期状态”被拒绝访问。

4.5 NIST SP 1800-35 的补充（2025）

NIST 在 2025 年 6 月发布了 SP 1800-35（Implementing a Zero Trust Architecture），这是一份与 24 个厂商合作的实际实现指南，包含了 19 种企业构建示例，按三个成熟度阶段组织：

• Crawl 阶段：增强身份治理——ICAM 系统承担 PDP 角色
• Run 阶段：独立的 PE/PA 组件 + 设备发现 + 云资源
• Full 阶段：SDP、微分段、SASE 的完全集成

SP 1800-35 的核心结论之一：没有单一厂商可以提供完整的零信任方案——所有 19 种构建都集成了来自多个厂商的 ICAM、终端安全、安全分析和策略执行产品。零信任不是买一个产品，而是组装一套架构。

五、工程上的关键分歧

NIST 的架构文档是共识的产物，但工程社区对几个关键点仍有分歧：

5.1 “持续验证”是多频繁？

NIST 说”持续”，但没有给频率。当前实践的分界线：

• 每个请求都评估：最严格，延迟和计算成本最高。Cedar 的 WASM 进程内执行使得这个模式在性能上可行。
• 每次令牌续期时评估：例如 JWT 有效期 5 分钟，续期时重新跑信任算法。这是当前最主流的折中。
• 事件驱动评估：平时不主动评估，只在收到风险事件信号（如设备不合规、威胁情报新告警）时触发降级。

5.2 PEP 应该多厚？

PEP 在架构图上是一个框，但工程上有两种极端实现：

• 瘦 PEP：PEP 只是一个转发层——收到请求，原样转发给 PDP，收到 allow/deny 后执行。PEP 本身不做任何决策。
• 胖 PEP：PEP 在本地缓存策略和信任算法所需的部分数据（如设备证书吊销列表），可以在 PDP 不可达时做”紧急模式”的决策（通常是拒绝）。

“瘦 PEP”更容易保证一致性（所有决策集中在 PDP），但引入了额外延迟和 PDP 的可用性压力。“胖 PEP”在 PDP 不可用时可以降级服务（如只允许访问低敏感资源），但 PEP 之间的策略缓存一致性成了一个分布式系统问题。

六、总结

NIST SP 800-207 的 7 条原则只是它的摘要。它的真正价值在于：

1. 逻辑组件模型：PEP/PDP/PE/PA 的分工——不是具体产品，而是评估任何零信任实现的一组追问。一个自称”零信任”的产品在架构图上对应哪个（或哪些）组件？它替代了什么、依赖什么？
2. 信任算法：零信任的核心不是”不信任”，而是 trust is computed——信任是一个动态计算的结果，不是一个静态分配的标签。信任算法的输入源、模型选择和衰减机制是零信任工程的真正复杂度所在。
3. 有意留白的工程决策：PDP 的状态管理、策略传播延迟、设备数据库一致性——这些不是 NIST 的疏忽，而是每个组织必须根据自己的环境和风险偏好做出的架构选择。

下一篇拆解 BeyondCorp 六篇论文全景，看 Google 在 NIST 写规范之前就实际跑了 4 年零信任迁移的工程记录。

参考资料

1. Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207.
2. National Cybersecurity Center of Excellence. (2025). Implementing a Zero Trust Architecture. NIST Special Publication 1800-35.
3. Cloud Security Alliance. (2014). Software Defined Perimeter (SDP) Specification 1.0.