零信任网络架构图模板

按照 NIST SP 800-207 绘制零信任架构图:PEP、PE、PA、信号来源、控制平面与数据平面的划分,以及一个免费模板。

2026/10/16

零信任网络架构图模板

很多标着“零信任”的图,其实只是换了标题的边界(perimeter)图:边缘一道防火墙,一个 DMZ,以及一个被信任的内网。一张有用的零信任架构图应当让人一眼回答三个问题:每个访问决策在哪里做出?哪些信号输入了这个决策?决策在哪里被强制执行?如果图回答不了这些问题,它描述的是网络位置,而不是信任。

本文内容:NIST SP 800-207 的逻辑模型、评审者可以逐条核对的绘图规则、常见错误,以及一个可以复制到 Archboard 中的免费模板。

NIST SP 800-207 的模型

NIST SP 800-207 围绕一个核心思想定义零信任架构(ZTA):不存在基于网络位置或资产归属的隐式信任。对每个资源的访问按会话授予,由动态策略决定,并在主体到达资源之前强制执行。

三个逻辑组件

组件 作用 画在哪里
Policy Engine (PE) 基于策略和数据源的输入(“信任算法”)做出授予、拒绝或撤销的决定 控制平面
Policy Administrator (PA) 执行 PE 的决定:建立或拆除会话路径,签发会话专用的凭据或令牌,配置 PEP 控制平面
Policy Enforcement Point (PEP) 启用、监控并终止主体与资源之间的连接 数据平面,并有一条通往 PA 的控制通道

PE 和 PA 合起来构成 Policy Decision Point(PDP)。在真实系统中,PE 可能位于身份感知代理或服务网格的控制平面之内,而 PEP 则是网关、sidecar、代理程序(agent)或代理服务器。即使一个产品同时承担两个角色,图中也应当让每个角色清晰可见。

决策背后的数据源

SP 800-207 列出了 PE 可以使用的输入。几乎每张图都应包含以下几类:

  • 身份提供商 / 身份管理:用户、服务身份、用户组、认证强度。
  • 设备状态(CDM):持续诊断与缓解数据——设备是否已知、是否受管、补丁是否到位?
  • 威胁情报:关于新攻击、被盗账号和漏洞的情报源。
  • 活动日志与 SIEM:收集并分析的网络与系统活动;反馈回路从这里开始。
  • 企业 PKI:面向用户、设备和工作负载的证书。

标准还提到数据访问策略和合规要求;如果它们确实影响决策,也把它们画出来。

如何绘制零信任架构图

1. 在每条访问路径上放一个 PEP

沿着每一条从主体(用户、设备、服务)指向资源的箭头追踪。每一条都必须先经过一个强制执行点。如果某条箭头绕过了 PEP,要么图画错了,要么架构存在缺口。除了用户路径,还要包括管理员、CI/CD 和紧急访问(break-glass)路径。

2. 展示身份和设备信号如何输入决策

把身份提供商、设备状态、威胁情报和 SIEM 画成节点,并用连线连到 Policy Engine。在连线上标注流动的内容,例如“用户 + 用户组(OIDC)”“设备合规状态”“风险信号”。

3. 明确按会话进行的认证与授权

NIST 将访问描述为按会话授予;许多实现会在每个请求上重新评估。无论哪种方式,都要展示这个顺序:主体请求访问,PEP 询问 PDP,PE 进行评估,PA 配置 PEP,PEP 放行或阻断会话。在连线上加编号标签就足够了;需要更多细节时,在旁边补一张小的时序图。

4. 把控制平面和数据平面分开

把 PE、PA 和数据源放在一个区域,把主体、PEP 和资源放在另一个区域。两个区域之间只应有 PA 到 PEP 的控制通道、信号输入和日志流。

5. 展示微分段和东西向流量

零信任不只关乎用户访问应用。对于服务之间的流量,要画出:

  • 工作负载身份(例如绑定到 service account 的证书),
  • 服务之间的 mTLS,以及签发这些证书的 CA 或 PKI,
  • 工作负载之间的分段策略,例如 Kubernetes NetworkPolicy。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orders-allow-from-checkout
  namespace: orders
spec:
  podSelector:
    matchLabels:
      app: orders
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: checkout
          podSelector:
            matchLabels:
              app: checkout
      ports:
        - protocol: TCP
          port: 8443

NetworkPolicy 工作在第 3 层和第 4 层,并且只有在你的 CNI 插件支持时才会生效。它是分段,不是认证,因此在图中要与 mTLS 以及 PEP 上的授权一起展示。

6. 把密钥和证书当作一等组件来画

把 vault(密钥管理器)和 PKI 画成独立的节点。画出哪些工作负载以什么身份获取哪些密钥。在 NIST 的模型中,会话专用凭据由 PA 签发,所以要把它们连到决策流程上。

7. 保留 WAF 和防火墙,但放对位置

零信任并不会去掉 WAF 或防火墙。它们仍然在边缘和网段之间做过滤,但它们不做信任决策。把它们画成路径上的过滤器,而不是围住“可信区域”的城墙。

8. 用日志闭合回路

每个 PEP 和防火墙都应把日志发送到 SIEM,分析结果再反馈给 Policy Engine。缺了这条连线,“持续验证”中的“持续”就从图中消失了。

零信任架构图:身份、设备状态、威胁情报、数据访问策略和 SIEM 信号输入 Policy Engine;Policy Administrator 控制位于用户设备与通过 mTLS 通信的资源之间的 PEP 网关。

17 个组件 · 13 个连接

在 Archboard 中打开
图表内容
  • Signals
  • Control plane
  • Data plane
  • Resources · micro-segmented
  • Identity provider
  • Device posture (CDM)
  • Threat intelligence
  • Data access policy
  • SIEM · activity logs
  • Policy Engine (PE)
  • Policy Administrator (PA)
  • User + device
  • PEP · access gateway
  • orders-api
  • billing-api
  • orders-db
  • PKI · mTLS certs
  • identity
  • posture
  • decision
  • allow / deny session
  • request
  • authorized session
  • mTLS
  • SQL · TLS
  • certs
  • logs
用图呈现 NIST SP 800-207 模型:各类信号输入 Policy Engine,Policy Administrator 配置 PEP,只有经过授权的会话才能到达微分段的资源。

常见错误

  • 换了标签的城堡加护城河。 一道厚厚的外部防火墙,一个“可信内网”,内部服务之间没有任何强制执行点。
  • 没有策略决策流程。 画布上有 IdP 和网关,却看不出决策在哪里做出、依据什么。
  • 没有反馈回路。 日志无处可去,或者 SIEM 是条死胡同,没有连回策略。
  • 只有南北向。 画了用户到应用的路径,却没有服务到服务、管理员到基础设施的路径。
  • 把区域画成信任。 用 Frame 表示网段没问题,但请把它们命名为网段或强制执行域,而不是“可信”。

在 Archboard 中绘制

内置节点包已经覆盖了所需的组件。Security 包提供身份提供商、WAF、防火墙、零信任网关、vault 和证书节点。Network 包提供 Internet、DNS、负载均衡器,以及以 frame 形式绘制的 VPC 和子网。Kubernetes 包补充了 Namespace(以 frame 形式绘制)、Service、Pod 和 NetworkPolicy。节点带有端口,因此每条连线都连接到节点的某一侧,而不是浮在一个图形上。

  1. 用 Frame 划分平面。 添加两个 Core 包的 Frame:“Control plane”和“Data plane”。在数据平面内为每个网段添加一个 Frame,例如“Edge”“App segment”和“Data segment”。Kubernetes 工作负载使用 Namespace 节点。
  2. 添加主体和边缘。 为用户放置一个 Network 包的 Internet 节点,接着放一个 Security 包的 WAF 节点,再放置零信任网关节点作为用户访问的 PEP。
  3. 添加决策及其输入。 在控制平面 frame 中放置身份提供商节点,以及标注为“Policy Engine”“Policy Administrator”“Device posture (CDM)”“Threat intel”和“SIEM”的 Core 包 Box 节点。
  4. 连接决策流程。 将各信号来源连到 Policy Engine,Policy Engine 连到 Policy Administrator,Policy Administrator 连到每个 PEP。给连线加上标签。
  5. 添加东西向路径。 在每个 Namespace 中添加 Service 和 Pod 节点以及一个 NetworkPolicy 节点。添加一个证书节点作为 mTLS 签发方,再添加一个 vault 节点存放密钥,并连到使用它们的工作负载。
  6. 在网段之间放置防火墙。 在流量跨越网段 frame 的位置使用 Security 包的防火墙节点。
  7. 闭合回路。 从每个 PEP 和防火墙画连线到 SIEM,再从 SIEM 连回 Policy Engine。
  8. 把假设写在画布上。 用 Markdown 块记录策略规则和会话时长,并在其中用 YAML 围栏代码块写 NetworkPolicy。

这样一张完整的图可能会超过 Free 套餐每张图 15 个图表节点的上限;便签和文本另行计算,最多 150 个。在 Free 套餐下,可以拆成一张总览图和一张 Kubernetes 细节图;Pro 套餐取消了节点上限。你可以导出 SVG 或 PNG(Free 套餐带水印),分享公开链接,并导出结构化 JSON,与基础设施代码放在一起管理。

免费模板

Zero Trust Perimeter 示例展示了用户经由边缘 WAF 进入、通过 OIDC 连接的 IdP / SSO 节点、零信任网关、网段防火墙、密钥 vault,以及围绕私有应用的 mTLS PKI。打开它,通过使用此示例把它复制到你的工作区。之后再按本文的内容补上控制平面 frame、信号来源和日志回路。底层网络部分可参考数据中心网络示例和网络图使用场景。

检查清单与常见问题

分享这张图之前,请确认:

  • 每条从主体到资源的路径都经过一个 PEP;
  • 身份、设备、威胁和日志信号都输入到 Policy Engine;
  • 控制平面和数据平面在视觉上明确分开;
  • 东西向流量展示了 mTLS 和分段;
  • 密钥和 PKI 标明了谁获取什么;
  • PEP 和防火墙的日志流向 SIEM,并回到策略。

零信任架构图只是网络图吗? 不是。网络图展示数据包去往哪里。ZTA 图在此基础上展示访问在哪里、依据哪些信号做出决策,以及在哪里强制执行。

零信任设计中还需要防火墙吗? 需要。防火墙和 WAF 依然能缩小暴露面,只是它们不再是“某样东西可信”的理由。

Kubernetes NetworkPolicy 就能实现零信任吗? 单靠它不行。它提供的是 L3/L4 分段。你仍然需要工作负载身份、mTLS、PEP 上的授权以及日志。

免费开始——一个席位,无需信用卡

相关文章

← 返回博客

一分钟打开画布

使用 Google 或 GitHub 登录。单席位免费,团队加入后再升级。