很多标着“零信任”的图,其实只是换了标题的边界(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。缺了这条连线,“持续验证”中的“持续”就从图中消失了。
图表内容
- 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
常见错误
- 换了标签的城堡加护城河。 一道厚厚的外部防火墙,一个“可信内网”,内部服务之间没有任何强制执行点。
- 没有策略决策流程。 画布上有 IdP 和网关,却看不出决策在哪里做出、依据什么。
- 没有反馈回路。 日志无处可去,或者 SIEM 是条死胡同,没有连回策略。
- 只有南北向。 画了用户到应用的路径,却没有服务到服务、管理员到基础设施的路径。
- 把区域画成信任。 用 Frame 表示网段没问题,但请把它们命名为网段或强制执行域,而不是“可信”。
在 Archboard 中绘制
内置节点包已经覆盖了所需的组件。Security 包提供身份提供商、WAF、防火墙、零信任网关、vault 和证书节点。Network 包提供 Internet、DNS、负载均衡器,以及以 frame 形式绘制的 VPC 和子网。Kubernetes 包补充了 Namespace(以 frame 形式绘制)、Service、Pod 和 NetworkPolicy。节点带有端口,因此每条连线都连接到节点的某一侧,而不是浮在一个图形上。
- 用 Frame 划分平面。 添加两个 Core 包的 Frame:“Control plane”和“Data plane”。在数据平面内为每个网段添加一个 Frame,例如“Edge”“App segment”和“Data segment”。Kubernetes 工作负载使用 Namespace 节点。
- 添加主体和边缘。 为用户放置一个 Network 包的 Internet 节点,接着放一个 Security 包的 WAF 节点,再放置零信任网关节点作为用户访问的 PEP。
- 添加决策及其输入。 在控制平面 frame 中放置身份提供商节点,以及标注为“Policy Engine”“Policy Administrator”“Device posture (CDM)”“Threat intel”和“SIEM”的 Core 包 Box 节点。
- 连接决策流程。 将各信号来源连到 Policy Engine,Policy Engine 连到 Policy Administrator,Policy Administrator 连到每个 PEP。给连线加上标签。
- 添加东西向路径。 在每个 Namespace 中添加 Service 和 Pod 节点以及一个 NetworkPolicy 节点。添加一个证书节点作为 mTLS 签发方,再添加一个 vault 节点存放密钥,并连到使用它们的工作负载。
- 在网段之间放置防火墙。 在流量跨越网段 frame 的位置使用 Security 包的防火墙节点。
- 闭合回路。 从每个 PEP 和防火墙画连线到 SIEM,再从 SIEM 连回 Policy Engine。
- 把假设写在画布上。 用 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 上的授权以及日志。